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 7/9/07, Alexandre Oliva <aoliva@redhat.com> wrote:
On Jul 9, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:

> On 7/9/07, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Jul  9, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:
>>
>> > So improve the way we are collecting information to produce debug info,
>> > but not disable optimizations.
>>
>> +1
>>
>> The patch I proposed has already been shown to not disable
>> optimizations, so I don't see what you're arguing for.

> It disables variable coalescing which is an optimization.

Make that "transformation".  It was shown to decrease overall
performance on few-register arches, and to do so even on many-register
arches for some specific testcases.

> Well, I see no reason we need to increase memory usage for the case
> '-g' is not specified.

Because GCC is by design a compiler that generates the very same code
regardless of -g.  We can't refrain from making certain
transformations depending on -g, because they might change the
generated code.

My suggestion isn't to make a transformation dependent on g.


The mere presence of line number notes or other
annotations has been shown to have effects on certain other
transformations.  For example, the presence of trees holding location
information could affect decisions about inlining or loop unrolling,
and the presence of line number notes in RTL did cause some
differences in code with or without -g in the past.

I'm very well ware of this. I suggested to have a on-the-side mapping (you need it for each function), like a hashtable that maps the SSA_NAME version to a list of user-visible DECLs. This doesn't change the IL and so doesn't create different code if you are using -g or not. You would need to maintain this mapping during optimization passes, but this isn't different to the problem you are facing now. Just it would not be business of the IL to hold the information.

Richard.


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