On Tue, May 25, 2010 at 10:02 PM, Easwaran Raman <era...@google.com> wrote:
> On Fri, May 21, 2010 at 10:30 AM, Xinliang David Li <davi...@google.com>
> wrote:
>>
>> On Fri, May 21, 2010 at 2:24 AM, Richard Guenther
>> <richard.guent...@gmail.com> wrote:
>> > On Thu, May 20, 2010 at 11:21 PM, Xinliang David Li <davi...@google.com>
>> > wrote:
>> >> On Thu, May 20, 2010 at 2:18 PM, Steven Bosscher <stevenb....@gmail.com>
>> >> wrote:
>> >>> On Thu, May 20, 2010 at 11:14 PM, Xinliang David Li <davi...@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.
