PATCH for alias sets/stack slots, again

Mark Mitchell mark@markmitchell.com
Fri Feb 19 00:09:00 GMT 1999


>>>>> "Jeffrey" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

    Jeffrey>   In message
    Jeffrey> < 199902180040.QAA22474@adsl-206-170-148-33.dsl.pacbell.net >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@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com


More information about the Gcc-patches mailing list