This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: no_new_pseudos


Alexandre Oliva <aoliva@redhat.com> writes:
> On Jul  4, 2007, David Edelsohn <dje@watson.ibm.com> wrote:
>
>>>>>>> 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 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 willing to clean things up from this point on may
> have to use complex grep patters to account for ongoing line breaks,
> reformatting and any other boolean transformations, just because it
> had to be expanded right away rather than retained as a macro?
>
> What I'm proposing is just that, instead of
>
>   s/no_new_pseudos/(reload_in_progress || reload_completed)/g
>
> we use
>
>   s/no_new_pseudos/!BEFORE_RELOAD_P ()/
>
> or at least keep no_new_pseudos as a macro that can be easily grepped
> for and doesn't break line length limits in current sources.
>
> I'm not asking for any actual cleanups to be reverted, just that we
> don't make it even harder to further clean it up.  If taking out one
> of these three variables is good, taking out another of them is going
> to be better, right?  Making it harder (or, more accurately, uglier)
> to do so isn't helping.

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
follow-on change is implemented -- but I don't understand why.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]