This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Reduce iterations of elimination bookkeeping
Jeff Law wrote:
> Vladimir Makarov wrote:
>> Jeff, sorry. I thought too that the patch makes compiler faster (and
>> it was quite obvious for me). But valgrind --tool=lackey actually
>> shows 0.3% more executed insn s for -O2 combine.i on x86 after
>> applying the patch. I think the problem may be (at least partially)
>> in bigger code generation, e.g. for combine.i
>>
>> 83082 0 792 83874 147a2 c0.o
>> 83098 0 792 83890 147b2 c1.o <- after
>> the patch
>>
>> I see also that compiler allocates bigger stack space for many
>> functions after applying the patch even in cases when all stack
>> displacements are the same. I have no idea why is that.
> I'm withdrawing the patch. I've probably already spent more time
> dorking around with it than I should.
Thanks anyway, it was an instructive experiment. When I'm debugging stack
layout issues I've often wished to see a whole lot less printf-spew from
INITIAL_FRAME_POINTER_OFFSET!
> For future reference, the multiple stack alignments occur when we spill
> a pseudo to memory after aligning the stack. The spill allocates a new
> stack slot and forces the big loop to iterate. If on that next
> iteration the stack isn't properly aligned, then we align it again (and
> again and again if we continue to have to spill pseudos to memory on
> subsequent iterations).
>
> Ideally, we'd align the stack once, after everything has been reloaded
> and not iterate. The current structure of this code doesn't allow for
> that possibility.
(Hypothetical) If we were rewriting it from scratch, do you think it would
be possible to keep the whole set of layout constraints and dependencies in
some kind of representation in memory and just incrementally update everything
each time 'something changes' in both elimination bookkeeping and
caller-save-setup on the fly, and call each once and not iterate at all?
cheers,
DaveK