On Thu, May 27, 2010 at 2:38 AM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> On Wed, May 26, 2010 at 6:05 PM, Richard Guenther
> <richard.guent...@gmail.com> wrote:
>> 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.
>
> Btw, globbing shared vars into a union will certainly also affect SRA,
> no?
>
It certainly will affect it.
David
> Richard.
>
>>> 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.
>>
>
