that predicate into different
things (no_new_pseudos vs. reload_completed, e.g.) is exactly the sort of
thing that happens when we lose this explicitness and the argument for
restoring it.
Since that would be obviously nonsensical, it must not be what I
meant. I must have meant what I said
in
the middle end and requiring the back end to use it is exposing the
guts of the middle end to the back end. That's breaking abstraction
layers. That's bad software engineering in general.
Note that that is exactly what was happening before. no_new_pseudos
denoted internal state in the middle end
the expanders need to know is can I create a pseudo now?. This does
translate into a state of compilation but that's not the needed
abstraction. What's happened is both that parts of the compiler have used
no_new_pseudos for both its original purpose and as a state of
compilation flag
, creating a BAD abstraction.
What the expanders need to know is can I create a pseudo now?. This does
translate into a state of compilation but that's not the needed
abstraction. What's happened is both that parts of the compiler have used
no_new_pseudos for both its original purpose
just as a small point, at least the ppc does behave differently with my
patch then without it. Apparently there areplaces, at least in the ppc
backend that did not generate pseudos before reload because of the
abstraction that are now able to generate them.
I'm sure that's true.
I am going to argue that it was a bug that we did not allow new
pseudos after flow had ran. And that we should have always allowed
pseudos before the register allocator. Since flow was so broken, we
could not, we added the hack no_new_pseudos get around that problem.
Now we are saying
Paolo Bonzini [EMAIL PROTECTED] writes:
I am going to argue that it was a bug that we did not allow new
pseudos after flow had ran. And that we should have always allowed
pseudos before the register allocator. Since flow was so broken, we
could not, we added the hack no_new_pseudos get
This discussion has gotten far too abstract for me.
Alexandre, please write your own patch, and we will approve it or not.
Or tell us how you think my patch should be changed.
Give us code, not discussion. I have already spent more time writing
e-mail messages than I've spent writing the patch.
was so broken, we
could not, we added the hack no_new_pseudos get around that problem.
Now we are saying it is a nice abstraction but I am saying this
abstraction should never have happened in the first place. We now
have a better compiler due to the removal of the hack.
The bad
On Jul 9, 2007, Andrew Pinski [EMAIL PROTECTED] wrote:
Since flow was so broken, we
could not, we added the hack no_new_pseudos get around that problem.
Now we are saying it is a nice abstraction but I am saying this
abstraction should never have happened in the first place.
You're
On Jul 9, 2007, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Or tell us how you think my patch should be changed.
#define no_new_pseudos (reload_in_progress || reload_completed)
if you want to reword it into a functional macro without a negative,
then it would take modifying back-ends as well
We've moved past that option, now we're arguing about using
regalloc_started_p ().
I'm against that. Why are we hardwiring that as the point at which no new
pseudos can be created? It seems right for now, but suppose we later have
some mechanism for doing regalloc on the fly?
If you want to
On Jul 9, 2007, at 11:04 AM, Ian Lance Taylor wrote:
OK, what do you think of this patch?
In hopes of ending this thread, I like this color of red... :-)
On 09 July 2007 19:24, Eric Botcazou wrote:
Note that I spent less time writing this patch than I did replying to
the e-mail messages on this thread.
You're probably going to hit the roof :-) but could you rename the predicate
to can_create_pseudo_p? may is somewhat ambiguous for
On Jul 9, 2007, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Alexandre Oliva [EMAIL PROTECTED] writes:
On Jul 9, 2007, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Or tell us how you think my patch should be changed.
#define no_new_pseudos (reload_in_progress || reload_completed)
if you
Eric Botcazou [EMAIL PROTECTED] writes:
Note that I spent less time writing this patch than I did replying to
the e-mail messages on this thread.
You're probably going to hit the roof :-) but could you rename the predicate
to can_create_pseudo_p? may is somewhat ambiguous for non-native
Ian Lance Taylor wrote:
Eric Botcazou [EMAIL PROTECTED] writes:
Note that I spent less time writing this patch than I did replying to
the e-mail messages on this thread.
You're probably going to hit the roof :-) but could you rename the predicate
to can_create_pseudo_p? may is
adding some extra internals
documentation about it, but I think the fact that it's been called
no_new_pseudos for so long suggests that we should just leave it
called that if we want a predicate that means the same thing.
--
Daniel Jacobowitz
CodeSourcery
adding some extra internals
documentation about it, but I think the fact that it's been called
no_new_pseudos for so long suggests that we should just leave it
called that if we want a predicate that means the same thing.
The reason to change it is that no_new_pseudos has been misused
it
with a macro, and I'd applaud adding some extra internals
documentation about it, but I think the fact that it's been called
no_new_pseudos for so long suggests that we should just leave it
called that if we want a predicate that means the same thing.
I agree. This is unnecessary churn that'll do nothing
Alexandre Oliva [EMAIL PROTECTED] writes:
Note that I spent less time writing this patch than I did replying to
the e-mail messages on this thread.
Yes, it's frustrating, but my experience has been that getting
consensus is generally much more difficult than implementing an
agreed-upon
up the definition and/or replacing it
with a macro, and I'd applaud adding some extra internals
documentation about it, but I think the fact that it's been called
no_new_pseudos for so long suggests that we should just leave it
called that if we want a predicate that means the same thing
Kenneth Zadeck [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
Eric Botcazou [EMAIL PROTECTED] writes:
Note that I spent less time writing this patch than I did replying to
the e-mail messages on this thread.
You're probably going to hit the roof :-) but could you
Shouldn't we see this as a teachable moment for correct English
grammar?
That would be overloading the predicate. :-)
More seriously:
[EMAIL PROTECTED]:~/svn/gcc/gcc grep ^may_ *.c
fold-const.c:may_negate_without_overflow_p (tree t)
haifa-sched.c:may_trap_exp (rtx x, int is_store)
On Mon, Jul 09, 2007 at 11:54:39AM -0700, Ian Lance Taylor wrote:
Kenneth Zadeck [EMAIL PROTECTED] writes:
Ian Lance Taylor wrote:
Eric Botcazou [EMAIL PROTECTED] writes:
Note that I spent less time writing this patch than I did replying to
the e-mail messages on this
Eric Botcazou [EMAIL PROTECTED] writes:
tree-ssa-loop-im.c:may_move_till (tree ref, tree *index, void *data)
tree-ssa-loop-prefetch.c:may_use_storent_in_loop_p (struct loop *loop)
So there are some existing cases of asking permission using may.
Joe Buck [EMAIL PROTECTED] writes:
May can
Eric Botcazou [EMAIL PROTECTED] writes:
tree-ssa-loop-im.c:may_move_till (tree ref, tree *index, void *data)
tree-ssa-loop-prefetch.c:may_use_storent_in_loop_p (struct loop *loop)
So there are some existing cases of asking permission using may.
Joe Buck [EMAIL PROTECTED] writes:
May can
Joe can open the door during the meeting could mean Joe is able to
open the door (e.g., he has the keys) or from time to time, Joe will
open the door during the meeting (e.g., it has been known to happen).
But I agree that it doesn't seem to be used that way in gcc.
And in compilers in
cleaning up the definition and/or replacing it
with a macro, and I'd applaud adding some extra internals
documentation about it, but I think the fact that it's been called
no_new_pseudos for so long suggests that we should just leave it
called that if we want a predicate that means the same thing
an irrelevant point,
but I'll show below why it is more relevant than it seems.
regalloc_started_p is still at a lower level of abstraction than
no_new_pseudos. Just because no_new_pseudos can be currently
implemented in terms of regalloc_started_p, it's not obvious that it
will remain so.
Consider
arbitrarily or
randomly. The backends already know that only the insns which have to
check no_new_pseudos are the move expanders and the splitters. For
example, look for calls to gen_reg_rtx in i386.md. Most of them do
not check no_new_pseudos, and they don't have to. If you want your
more general
?
To be blunt: no, I don't. I see a set of hypothetical possibilities,
none of which I consider to be at all likely.
To be even more blunt, I never viewed no_new_pseudos as a useful abstraction
It was a gate that protected a set of badly designed concrete
datastructures.
Those datastructures
On Jul 8, 2007, Kenneth Zadeck [EMAIL PROTECTED] wrote:
To be even more blunt, I never viewed no_new_pseudos as a useful abstraction
It was a gate that protected a set of badly designed concrete
datastructures.
I can appreciate that this is a valid point of view for the
implementation
the
guts of the middle end to the back end. That's breaking abstraction
layers. That's bad software engineering in general.
Note that that is exactly what was happening before. no_new_pseudos
denoted internal state in the middle end. You are repurposing it from
something bad to something good
On Jul 5, 2007, Richard Sandiford [EMAIL PROTECTED] wrote:
Ian Lance Taylor [EMAIL PROTECTED] writes:
I think the best option is for somebody to go through the uses of
no_new_pseudos and fix them. Incomplete transitions are bad.
I admit I'm still not sure on this point, and seeing fix
Alexandre Oliva writes:
Alexandre Collapsing no_new_pseudos with anything else that doesn't carry the
Alexandre semantics it currently expresses is a transformation that loses
Alexandre information. Pretty please don't do this just because the current
Alexandre code doesn't care about
preventing incremental
improvement in GCC.
I don't understand what you mean here. I'm asking for the target uses
of no_new_pseudos to be kept the same -- with no_new_pseudos defined as
a macro, if necessary -- whereas Kenny is trying to get rid of them.
Surely getting rid of something is a more
On Jul 6, 2007, David Edelsohn [EMAIL PROTECTED] wrote:
Alexandre Oliva writes:
Alexandre Collapsing no_new_pseudos with anything else that doesn't carry the
Alexandre semantics it currently expresses is a transformation that loses
Alexandre information. Pretty please don't do this just
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
That's why it seems so odd to me to want to get rid of the port uses
and not replace it with something directly equivalent. I just don't
see how it qualifies as a clean-up. I think tying the ports even
!BEFORE_RELOAD_P() out of the expanded version of no_new_pseudos.
Except that no_new_pseudos was not used consistently.
I'm not sure what you mean by consistently, but regardless, how
could any argument possibly make it better to replace it with
(reload_in_progress || reload_completed
Richard Sandiford [EMAIL PROTECTED] writes:
For the record, Alex puts my point of view perfectly here too.
I gather from the follow-ups that there's resistance to
s/no_new_pseudos/!BEFORE_RELOAD_P ()/ -- with BEFORE_RELOAD_P
defined as reload_in_progress || reload_completed until Alex's
Alexandre Oliva writes:
Except that no_new_pseudos was not used consistently.
Alex I'm not sure what you mean by consistently, but regardless, how
Alex could any argument possibly make it better to replace it with
Alex (reload_in_progress || reload_completed)
Alex rather than
Alex
David Edelsohn wrote:
Alexandre Oliva writes:
Except that no_new_pseudos was not used consistently.
Alex I'm not sure what you mean by consistently, but regardless, how
Alex could any argument possibly make it better to replace it with
Alex (reload_in_progress
On Jul 5, 2007, Kenneth Zadeck [EMAIL PROTECTED] wrote:
The work here is not changing the bits. the work here is the actual
auditing of each place to see if it was the correct place.
Then I guess the best option is to leave no_new_pseudos defined as a
macro, such that we can introduce
Alexandre Oliva [EMAIL PROTECTED] writes:
On Jul 5, 2007, Kenneth Zadeck [EMAIL PROTECTED] wrote:
The work here is not changing the bits. the work here is the actual
auditing of each place to see if it was the correct place.
Then I guess the best option is to leave no_new_pseudos
the best option is to leave no_new_pseudos defined as a
macro, such that we can introduce the enumeration and migrate to it in
a way that makes it clear what has been migrated and what hasn't.
I think the best option is for somebody to go through the uses of
no_new_pseudos and fix them. Incomplete
On Thu, 5 Jul 2007, Alexandre Oliva wrote:
We might want to take GDB's practice of adding DEPRECATED_ to
deprecated constructs, such that people who stumble across the code
are more likely to notice that it needs auditing and updating.
The GDB method (port x86-foo uses deprecated_something,
On Tue, Jul 03, 2007 at 05:14:21PM -0400, Kenneth Zadeck wrote:
David Edelsohn points out that some of the expanders could have all of
this code removed since expanders only run before reload. I do not know
how to figure this out.
The movM and addM3 expanders are used by reload. The
On 04 July 2007 17:41, Ian Lance Taylor wrote:
Richard Sandiford [EMAIL PROTECTED] writes:
What about the earlier idea of keeping no_new_pseudos and making it
equivalent to reload_in_progress || reload_completed, either by being
a macro or by being a variable?
I would prefer to get rid
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
What about the earlier idea of keeping no_new_pseudos and making it
equivalent to reload_in_progress || reload_completed, either by being
a macro or by being a variable?
I would prefer to get rid
#define BEFORE_RELOAD_P (!reload_in_progress !reload_completed)
I'd personally vote for something like this.
--
Eric Botcazou
Richard Sandiford writes:
Richard So which of (1) and (2) from my message do think is best? Replace
backend
Richard uses with reload_completed when doing so is safe, or consistently
replace
Richard it with reload_in_progress || reload_completed throughout the
backends?
Richard,
I
On 04 July 2007 18:03, Ian Lance Taylor wrote:
Richard Sandiford [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
What about the earlier idea of keeping no_new_pseudos and making it
equivalent to reload_in_progress
Richard Sandiford [EMAIL PROTECTED] writes:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Richard Sandiford [EMAIL PROTECTED] writes:
What about the earlier idea of keeping no_new_pseudos and making it
equivalent to reload_in_progress || reload_completed, either by being
a macro or by being
what you mean by the second sentence. The purpose of
the macro or alias is precisely to define what the agreed semantics are
(just as no_new_pseudos does now). My main concern...
Once this initial find-and-replace substitution is done, I am sure
that we all will be able to agree on way
for divergence.
I don't understand what you mean by the second sentence. The purpose of
the macro or alias is precisely to define what the agreed semantics are
(just as no_new_pseudos does now). My main concern...
From my point of view, my purpose to do this was to get all of the
unnecessary
On Jul 4, 2007, Richard Sandiford [EMAIL PROTECTED] wrote:
What about the earlier idea of keeping no_new_pseudos and making it
equivalent to reload_in_progress || reload_completed, either by being
a macro or by being a variable?
Actually, how about replacing the three variables with a single
On 04 July 2007 19:25, Alexandre Oliva wrote:
Actually, how about replacing the three variables with a single
tri-state variable that indicates the progress into reload:
enum { BEFORE_RELOAD = -1, DURING_RELOAD = 0, AFTER_RELOAD = 1 }
reload_status;
#define BEFORE_RELOAD_P()
myself: I prefer that this change be
made by someone who understands the backends well enough to simplify the
cases (not to mention the fact that there are 2000 grep hits of this
and there were only 200 of no_new_pseudos).
The purpose of my patch was to get rid of a variable that had not been
() (reload_status DURING_RELOAD)
I do not want to make this change myself:
It's as mechanical as the change you proposed, except that yours
potentially loses information that would enable someone to recover
!BEFORE_RELOAD_P() out of the expanded version of no_new_pseudos.
Cleanups can come up later
Alexandre Oliva writes:
Alexandre It's as mechanical as the change you proposed, except that yours
Alexandre potentially loses information that would enable someone to recover
Alexandre !BEFORE_RELOAD_P() out of the expanded version of no_new_pseudos.
Except that no_new_pseudos
version of no_new_pseudos.
Cleanups can come up later.
I find this argument somewhat suspect. At this point I know the middle
end quite well, and there I simply had to reason about each grep hit
given the context of where it was used.In the backends I applied the
transformation
Alexandre It's as mechanical as the change you proposed, except that yours
Alexandre potentially loses information that would enable someone to recover
Alexandre !BEFORE_RELOAD_P() out of the expanded version of no_new_pseudos.
Except that no_new_pseudos was not used consistently
of no_new_pseudos.
Except that no_new_pseudos was not used consistently.
I'm not sure what you mean by consistently, but regardless, how
could any argument possibly make it better to replace it with
(reload_in_progress || reload_completed)
rather than
!BEFORE_RELOAD_P()
such that anyone
On 03 July 2007 22:14, Kenneth Zadeck wrote:
David Edelsohn points out that some of the expanders could have all of
this code removed since expanders only run before reload. I do not know
how to figure this out.
I thought that movMM expanders could still be run /during/ reload, at the
very
I thought that movMM expanders could still be run /during/ reload, at the
very least? Or does some of the expanders mean excluding movMM in
particular? (I'm not sure if I should infer the word those between
removed since and expanders only).
Certainly movMM can run during reload. It was
Dave Korn wrote:
On 03 July 2007 22:14, Kenneth Zadeck wrote:
David Edelsohn points out that some of the expanders could have all of
this code removed since expanders only run before reload. I do not know
how to figure this out.
I thought that movMM expanders could still be run
I do not remember if it was stevenb or bonzini that observed that
because of changes that came with the dataflow branch it is now trivial
to get rid of no_new_pseudos. All of the sets can just go away, as well
as the tests of it that occur in passes that only run before reload.
For those few
I believe that the original purpose of this was to protect certain
datastructures that had to be resized manually when pseudos were added.
Correct.
Does anyone think this is a bad idea? A grep for no_new_pseudos bears
out that nothing is really going on here anymore.
Seems like a real
On Mon, 2007-07-02 at 12:10 -0400, Kenneth Zadeck wrote:
I do not remember if it was stevenb or bonzini that observed that
because of changes that came with the dataflow branch it is now trivial
to get rid of no_new_pseudos. All of the sets can just go away, as well
as the tests
There are 199 uses of it in the backends; compared to 32 in the front
end.
So it is quite heavily used by MD code.
That distinction shouldn't matter unless some of the MD code uses it instead
of reload_completed, which is (unfortunately) a real possibility.
So I fear those will have to be
Kenneth Zadeck wrote:
I do not remember if it was stevenb or bonzini that observed that
because of changes that came with the dataflow branch it is now trivial
to get rid of no_new_pseudos.
For the record, this was Steven's observation. And Kenner confirming
that this was the original
I fear those will have to be checked.
there are a few in the back ends that will require some thought. most
are trivial.
There appears to be an idiom, (or at least a chunk of code that has been
heavily copied) where *_output_mi_thunk sets reload_completed and
no_new_pseudos at the top
Kenneth Zadeck [EMAIL PROTECTED] writes:
There appears to be an idiom, (or at least a chunk of code that has been
heavily copied) where *_output_mi_thunk sets reload_completed and
no_new_pseudos at the top and clears them at the bottom.
This appears to be the majority of the not trivial
Kenneth Zadeck wrote:
I do not remember if it was stevenb or bonzini that observed that
because of changes that came with the dataflow branch it is now trivial
to get rid of no_new_pseudos.
For the record, this was Steven's observation. And Kenner confirming
that this was the original
On Jul 2, 2007, Richard Earnshaw [EMAIL PROTECTED] wrote:
On Mon, 2007-07-02 at 12:10 -0400, Kenneth Zadeck wrote:
I do not remember if it was stevenb or bonzini that observed that
because of changes that came with the dataflow branch it is now trivial
to get rid of no_new_pseudos. All
76 matches
Mail list logo
