Re: gcc 3.4 regression: sched2 moving "may throw" instructions into epilogue

[Jim Wilson <wilson at specifixinc dot com>]

Andrew Haley wrote:
> Is that right, though?  It's only trapping instructions that mustn't
> be moved into the epilogue, not all instructions.  This solution
> sounds like it would be an all-round performance loser.

I don't see any obvious way to restrict this to only trapping insns.  We 
could check for trapping insns when moving insns from one block to 
another.  However, in the normal case, the epilogue is not a block of 
its own, as the epilogue does not start with a code label.  Hence there 
is only intra-block movement here, and there are no checks for traps 
when doing intra-block scheduling, except for the obvious case that a 
trapping memory access is considered to conflict with other memory 
accesses.  So you could perhaps handle the trapping mem case with an asm 
that has a memory clobber.  However, that doesn't help you with trapping 
divides.

If you want to handle just trapping insns, then we would need a new kind 
of construct that conflicts only with trapping insns.  Perhaps something 
could be added to asms.  It is already the case that an asm can clobber 
"memory".  Perhaps we can add "traps" to the list.  And then if we see 
this special construct, we prevent any movement of other trapping 
instructions across it.

A more elegant solution is to just emit unwind info for epilogues, which 
the IA-64 port already does.  However, this would require changes to 
many targets, and so it is a lot more work.  It avoids the need for any 
optimizer changes though.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com