stack slot reuse

[Martin Jambor]

Hi,

I have not really payed much attention to this thread, but...

On Thu, May 27, 2010 at 11:38:09AM +0200, Richard Guenther wrote:
> On Wed, May 26, 2010 at 6:05 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
> > On Wed, May 26, 2010 at 5:42 PM, Xinliang David Li <davidxl@google.com> wrote:
> >> On Wed, May 26, 2010 at 2:58 AM, Richard Guenther
> >> <richard.guenther@gmail.com> wrote:
> >>> 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.
> >>
> >> 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?

If the variables have different sizes, only the smallest ones might
get a scalar replacement.

If the smallest variables have different types, you'll get a lot of
VIEW_CONVERT_EXPRs for all but one (more-or-less randomly) chosen
type.

But I guess you were primarily discussing variables that need to
reside in memory so it may not be such a big concern, after all.

Martin