PR 23551: why should we coalesce inlined variables?

Alexandre Oliva aoliva@redhat.com
Sun Jul 8 08:29:00 GMT 2007


On Jul  7, 2007, Jan Hubicka <hubicka@ucw.cz> wrote:

>> On Jun 28, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:
>> 
>> > I fooled around with some simple cases, and didn't find anything that
>> > made much difference.  Whats a testcase you have which shows this
>> > helping?
>> 
>> Err...  I'm sure I had something when I posted the patch, but the
>> build tree in which I came up with the testcase is long gone, and I no
>> longer remember the details.  On a more recent build tree, I couldn't
>> really find any case in which the patch really made a difference as to
>> debug info :-(

> this patch seems to be responsible for 90% memory consumption increase
> at rtl-optimization/28071 -O3:

And rightly so, I guess.  Formerly, we discarded information to the
point of making the program utterly undebuggable.

I understand that you're not compiling with -g and so you don't care
about debuggability, but a basic principle in GCC has always been that
-g shouldn't change the generated code in any way, so I guess we don't
have a choice: if we want to make this kind of program debuggable, we
have to pay the price of additional memory to compile it even without
debug info.

That said, maybe with the work I have in mind we'll be able to enable
coalescing for all user variables (not only those coming from inlined
functions), and retain the annotations needed to map the assignments
back to user variables somehow.  However, I'm not convinced yet that
it can be done in a way that consumes less memory, basically because
we'd have to keep track of which variables map to which assignments to
SSA variables, and this would amount to further SSA analysis and
assignments, or annotations that would have to be dealt with in a very
similar way.  That said, ideas are welcome.

-- 
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}



More information about the Gcc-patches mailing list