On Wed, May 26, 2010 at 5:42 PM, Xinliang David Li <davi...@google.com> wrote:
> 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?
It shouldn't. But SRA needs to be adjusted for sure.
> 2) inline summary also needs to be taught to not include size of those
> fake instructions;
That's simple. The inliner also needs to be taught to emit the
fake assignments into the caller.
> 3) why only aggregates? For scalars that live in
> stack, they also need barriers if slot sharing pick them as
> candidates, etc.
Sure.
Richard.
