This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stack slot reuse


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?

>
> 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.

Thanks,
Easwaran

>
> One of the other motivation for doing
> this is due to the limitation in current implementation that leaves
> out many overlaying opportunities (e.g. structs with union members can
> not share slots etc), but this is a probably independent issue.
>
>
> Thanks,
>
> David
>
> > which we'd expand to nothing. ?Of course shifting the problem to
> > the RTL optimizers, so better expand to a similar RTL construct.
> > But then are you addressing the similar problem on the RTL side?
> >
> > Richard.
> >


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]