On Mon, Jul 09, 2007 at 05:26:00PM -0400, Paolo Bonzini wrote:
>
> >"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
ing predicates
> > confusing. I applaud 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 w
"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
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:
> "Ma
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:
> "Ma
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-ma
> 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)
loop-in
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 roo
t; > confusing. I applaud 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
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
> agre
ith 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 tha
ith 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.
The reason to change it is
;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.
--
Daniel Jacobowitz
CodeSourcery
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_p
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
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.
>>
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 n
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... :-)
> 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
> 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 speakers.
--
Eric Botcazou
> The bad abstraction was causing quirks in *when* no_new_pseudos was set
> to 1. But no_new_pseudos is a good abstraction in itself, people are
> arguing on whether it is a better abstraction as "reload_in_progress ||
> reload_completed".
I argue that because both have his
> 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
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-end
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
; 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 it is a nice abstraction but I am saying this
> > > abstraction should never have happened in the first pla
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.
; 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 a
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 it is a
On 7/9/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
It's true that, before your patch, one couldn't create new pseudos
after flow analysis, and after your patch, one can create them all the
way until reload. 'no_new_pseudos' would still mean the same: it's
true
ecause of the abstraction'.
It's true that, before your patch, one couldn't create new pseudos
after flow analysis, and after your patch, one can create them all the
way until reload. 'no_new_pseudos' would still mean the same: it's
true if it's too late to creat
Richard Kenner wrote:
>> 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.
>>
> 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.
it as an effect of NOT creating an abstraction or, perhaps more
> precisely, 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
> abstr
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 i
meaning, and currently functional.
>>
>> Replacing that with some variable that denotes some internal state 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
>>
The
fact that backends have translated 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
state 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
denote
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
he back end. That's breaking abstraction
layers. That's bad software engineering in general.
> I have never liked no_new_pseudos, because it is a negative flag and
> therefore confusing to use.
Oh, if that's all, we can address that.
s,no_new_pseudos,!new_pseudos_acceptable_p
is a losing proposition in
>> the long run?
>>
>
> 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
cally, backend routines are never called 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&
nd I assume you meant it to become true
only when reload started. This might seem like 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 current
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 po
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> inf
is is a giant Bike Shed 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.
Surel
>>>>> 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
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'
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,
ng 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 the enumeration and migrate to it in
>> a way that makes it clear what has been migrated and what ha
I guess 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 f
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 c
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 r
>>>>> 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_pro
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_progres
y 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.
>
> I'm not sure what you mean by "consistentl
!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_progre
> 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 tha
>
> 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.
>
>
I find this argument somewha
>>>>> 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.
(reload_status == DURING_RELOAD)
>>> #define AFTER_RELOAD_P() (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
to me.
>
> cheers,
> DaveK
>
This seems like a reasonable idea.
I do not want to make this change 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
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() (relo
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 t
uld lead to confusion and creates an
>> opportunity 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.
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...
> Once this initial find-and-replace substitution is done, I am sure
> that
> 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,
> #define BEFORE_RELOAD_P (!reload_in_progress && !reload_completed)
I'd personally vote for something like this.
--
Eric Botcazou
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 keep
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
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
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 ma
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 of it and clean up afterward.
Ian
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 prolo
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 ru
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 s
> 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 re
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
ver
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
>> t
> 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
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 th
d_completed, which is (unfortunately) a real possibility.
>
> So 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
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 ori
> 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 b
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
> 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.
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
86 matches
Mail list logo
