On Wed, May 26, 2010 at 2:58 AM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> 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.
Other issues to consider: 1) how does it affect SRA decisions? 2)
inline summary also needs to be taught to not include size of those
fake instructions; 3) why only aggregates? For scalars that live in
stack, they also need barriers if slot sharing pick them as
candidates, etc.
>
>>> 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?
>
Debug information is handled. Easwaran can fill in the details.
Thanks,
David
> 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.
>
