Re: stack slot reuse

[Richard Guenther <richard dot guenther at gmail dot com>]

On Tue, May 25, 2010 at 10:02 PM, Easwaran Raman <eraman@google.com> wrote:
> On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li <davidxl@google.com> wrote:
>>
>> On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>> > On Thu, May 20, 2010 at 11:21 PM, Xinliang David Li <davidxl@google.com> wrote:
>> >> On Thu, May 20, 2010 at 2:18 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> >>> On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li <davidxl@google.com> wrote:
>> >>>> stack variable overlay and stack slot assignments is here too.
>> >>>
>> >>> Yes, and for these I would like to add a separate timevar. Agree?
>> >>
>> >> Yes. ?(By the way, we are rewriting this pass to eliminate the code
>> >> motion/aliasing problem -- but that is a different topic).
>> >
>> > Btw, we want to address the same problem by representing the
>> > points where (big) variables go out-of scope in the IL, also to
>> > help DSE. ?The original idea was to simply drop in an aggregate
>> > assignment from an undefined value at the end of the scope
>> > during lowering, like
>> >
>> > ?var = {undefined};
>> >
>>
>
> Is there something that prevents store sinking (or similar passes)
> from moving this 'var = {undefined};' statement outside the scope? Or
> should store sinking be taught to treat this as a barrier?

Not at the moment (if indeed that assignment looks as a regular one).
Passes should be taught that it's not worthwhile to sink a
no-op.  IIRC no pass currently would sink aggregate copies anyway.

>> This looks like a very interesting approach. ?Do you see any downside
>> of this approach? ?What is the problem of handling (nullifying) the
>> dummy statement in expansion pass?
>>
>> The approach we took is different --- we move this overlay/packing
>> earlier (after ipa-inlining).
>
> To elaborate further, we use the current stack-slot sharing heuristics
> in cfgexpand.c to decide what variables can share stack slots,
> synthesize union variables with those variables as fields and replace
> references to those variables with field references. We have an
> initial implementation and are evaluating the performance impact of
> making the sharing decisions early.

Note that using union variables will pessimize alias analysis
as we allow type-punning with unions.  How do you address
the issue of debug information?

Some time ago I had the very simple idea to merge identically
typed variables that do not have overlapping life-ranges into
a single variable (avoiding the union issue).  That would not
catch all cases cfgexpand catches but may even re-use
common initializations.  Of course the debug information
issues would be the same.

I think we want the clobbering stores anyway, for optimization
purposes, even if we do not end up using them for the
stack slot sharing problem.

Richard.