PATCH for alias sets/stack slots, again

Christian Bruel
Sun Feb 28 18:15:00 GMT 1999


Regarding the problem of reusing stack slots in register spilling, I noticed 
in gcc the following weirdness:
When a register, holding a value aliased to a global symbol, needs to be 
gcc could use its address instead of creating (or even reusing another) a 
stack slot.

I did the experiment by storing this information in reg_equiv_memory_loc, so
the memory reference is used when the spill comes, instead of a stack slot.

Here is the cut of the code (in reload1.c:reload), I'm worring about possible 
but this is the idea.



      /* If this insn is setting a MEM from a register equivalent to it,
	 this is the equivalencing insn.  */
      else if (set && GET_CODE (SET_DEST (set)) == MEM
	       && GET_CODE (SET_SRC (set)) == REG
	       && reg_equiv_memory_loc[REGNO (SET_SRC (set))]
	       && rtx_equal_p (SET_DEST (set),
			       reg_equiv_memory_loc[REGNO (SET_SRC (set))]))
	reg_equiv_init[REGNO (SET_SRC (set))]
	  = gen_rtx_INSN_LIST (VOIDmode, insn,
			       reg_equiv_init[REGNO (SET_SRC (set))])

>     else if (set && GET_CODE (SET_DEST (set)) == MEM
>	       && GET_CODE (XEXP (SET_DEST (set), 0)) == SYMBOL_REF
>	       && GET_CODE (SET_SRC (set)) == REG 
>	       && !reg_equiv_init[REGNO (SET_SRC (set))]
>	  reg_equiv_memory_loc[REGNO (SET_SRC (set))] = SET_DEST (set);	

      if (GET_RTX_CLASS (GET_CODE (insn)) == 'i')
	scan_paradoxical_subregs (PATTERN (insn))

> >>>>> "Jeffrey" == Jeffrey A Law <> writes:
>     Jeffrey>   In message
>     Jeffrey> < >you
>     Jeffrey> wri te:
>     >> 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?
>     Jeffrey> If the old slot has alias set zero and the desired alias
>     Jeffrey> set is zero, then we can reuse the slot.  Right?
> Nope.  I tried to explain this in the comments in the code, but I
> guess I failed.  :-(
> Suppose that we create a slot with alias set zero.  This means we know
> nothing about what will be there; suppose it's a stack frame for an
> inlined function, and the first 4 bytes become an int.  Then, if we
> reuse it for another inline where the 4 bytes are a long, we'll end
> up with references to the same piece of memory, sometimes thinking
> it's an int, and sometimes thinking it's a double.
>     Jeffrey> It also seems to me like we can combine slots when their
>     Jeffrey> alias sets match; however, I think the only time we'd
>     Jeffrey> want to do that is when both slots have alias set zero --
>     Jeffrey> it's unlikely a combined slot with a nonzero alias set
>     Jeffrey> will ever match anything.
> See above.  Similar issues.
>     Jeffrey> I'd suggest making dump_class have external linkage to
>     Jeffrey> keep the warning police happy.
> OK.  But, that also keeps optimizers from getting rid of it.  Haven't
> the warning police invented some way of marking a function
> for-debugging-purposes-only?  I'm fine with either approach on this.
>     Jeffrey> It'll be interesting to see how much additional stack
>     Jeffrey> space we end up using and if there's any noticable
>     Jeffrey> runtime impact.  Re-using stack slots introduces false
>     Jeffrey> dependencies similar to register allocation.  Which
>     Jeffrey> inhibibs the ability of the scheduler and/or hardware to
>     Jeffrey> exploit ILP.
> Right.
>     Jeffrey> Your idea of leaving in clobbers of MEMs after reload
>     Jeffrey> isn't bad.  Though don't you have to worry about regs
>     Jeffrey> which don't get regs and thus get turned into stack
>     Jeffrey> slots?
> Yes, probably. 
>     Jeffrey> Another approach would be for these stack slots to have
>     Jeffrey> lifetimes, just like registers.  We'd basically want to
>     Jeffrey> inhibit twoo initially disjoint lifetimes for a slot from
>     Jeffrey> ever overlapping due to optimizations.
> This would probably be the best, cleanest solution.  
>     Jeffrey> Another approach would be look at the problem as a pure
>     Jeffrey> dependency issue -- ie when we re-use a slot, that
>     Jeffrey> creates an edge in the dependency graph between the
>     Jeffrey> previous users and the new users.  The trick (of course)
>     Jeffrey> is how to represent those edges and keep them up to date
>     Jeffrey> through each pass in the compiler.
> This is a good idea, too.  As you note, though, these all take work!
> Let's keep scratching our heads; I'm sure that one of us will get to
> this in the next six months or so.  The more infrastructure we get in
> place (like RTH's flow-graph stuff), the easier it will be to think of
> ways to deal with this problem.
>     Jeffrey> Phew.  I guess the bottom line is if you'd prefer to go
>     Jeffrey> with this patch, it's OK after the minor changes
>     Jeffrey> suggested above.
> I'd like to get this in, for correctness.  I hate having a known-buggy
> compiler, even in snapshots.  It's hard to track down other problems.
> This way, we have a known stack-wasting compiler, which is much less
> likely to confuse the heck out of us.
> Please let me know if you buy my alias set zero comments above; when
> I've convinced you, or vice versa, I'll put the patch in.
> Thanks!
> -- 
> Mark Mitchell
> Mark Mitchell Consulting

More information about the Gcc-patches mailing list