PATCH for alias sets/stack slots, again

Jeffrey A Law
Thu Feb 18 23:42:00 GMT 1999

  In message < >you wri
  >   So, this patch restores correctness by (possibly) increasing the
  > amount of stack space required for a function; we only reuse a stack
  > slot if the thing to be placed there has the same type (well, alias
  > set) as the thing that was there before.  This fixes the problems that
  > I'm seeing, and does not seem, after some experimentation, to blow up
  > stack usage too badly.
  >   Jeff, may I check this in?
If the old slot has alias set zero and the desired alias set is zero, then we
can reuse the slot.  Right?

It also seems to me like we can combine slots when their alias sets match;
however, I think the only time we'd want to do that is when both slots
have alias set zero -- it's unlikely a combined slot with a nonzero alias
set will ever match anything.

I'd suggest making dump_class have external linkage to keep the warning
police happy.

It'll be interesting to see how much additional stack space we end up using
and if there's any noticable runtime impact.  Re-using stack slots introduces
false dependencies similar to register allocation.  Which inhibibs the
ability of the scheduler and/or hardware to exploit ILP. 

Additionally, stuff like slot splitting & combining may not make sense on
modern CPUs that recommend against referencing the same hunk of memory with
different sized operations.  

Your idea of leaving in clobbers of MEMs after reload isn't bad.  Though don't
you have to worry about regs which don't get regs and thus get turned into
stack slots?

Another approach would be for these stack slots to have lifetimes, just like
registers.  We'd basically want to inhibit twoo initially disjoint lifetimes
for a slot from ever overlapping due to optimizations.

This is similar to some stuff I've been mulling over for the tail/sibling call
work.  We need to know the lifetime of stack slots since we can't turn a normal
call into a tail/sibling call if there's s stack slot live at the call site.
The idea is to run a traditional life analysis pass on the stack slots to
determine all points where each slot is live.

Another approach would be look at the problem as a pure dependency issue -- ie
when we re-use a slot, that creates an edge in the dependency graph between
the previous users and the new users.  The trick (of course) is how to
represent those edges and keep them up to date through each pass in the

Phew.  I guess the bottom line is if you'd prefer to go with this patch, it's
OK after the minor changes suggested above.  Or we can look into other
solutions if you'd prefer to do that.


More information about the Gcc-patches mailing list