This is the mail archive of the gcc-patches@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: PR 23551: why should we coalesce inlined variables?


On Jul  9, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:

> It shoulnd't be too hard to get this working to the point that it is as good
> as with your patch disabling coalescing (which you say doesn't help anyway
> as optimization passes do this coalescing by propagation anyway).

That's the thing, I don't see how it's going to be accomplished if we
just throw that assignment away.  And if we don't, whether we coalesce
or not is irrelevant, we have to keep an annotation at that point to
indicate the state of some user variable changed at that point.  And
if we only add that annotation when generating debug information, odds
are that we'll change generated code depending on -g, which is a
non-starter.  So no matter how I look at it, there is going to be some
increase in memory use because we'll have to keep more info.

I have no doubt that there are different and quite likely more
efficient ways to do it than my first-cut approach that only removes
an artificial, arbitrary and incorrect distinction between certain
kinds of user variables.  As you suggested yourself, we'd be better
off making the change in the other direction, as in the new patch I've
proposed.

Then the work I'm supposed to be doing (rather than explaining why
better debug info is necessary ;-) will be able to make up for the
removed information.  But it will amount to some increase in memory
use, there's no escaping to it.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}


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