Fill more delay slots in conditional returns

Eric Botcazou ebotcazou@adacore.com
Sun Apr 14 14:21:00 GMT 2013


> I don't recall ever working on this aspect of reorg.  The obvious worry
> is that with reorg moving stuff around those notes may not be valid
> anymore in the general case.

Yes, in the general case I agree that's too dangerous.  In this particular 
case, i.e. backward scan only, this might be plausible, although one has 
probably to worry about what happens if the insn is removed from the delay 
slot and put back into the RTL stream.

> Just a note, there's a formatting error in this code.  The real_insn =
> statement is indented too far.  Feel free to fix that :-)

Patch attached (I've also reindented a block of code in reorg.c), tested on 
the SPARC and applied on the mainline.

> Seems reasonable.  This might just be an oversight by the original
> author.  Effectively we're going to start marking the referenced
> resources with your patch.  We still defer killing as far as I can tell.

OK.

> If you want to run with it, I won't object.  My worry would be we might
> not see the fallout for a long time as the number of things that have to
> fall into place for an observable failure here are very high.

Indeed, I spotted these two cases when I was playing with the allocation of 
registers for the private target.  They showed up only under very specific 
circumstances; with the default setting, neither makes a difference for the 
various testcases I'm looking at.  So, in the end, I probably won't pursue.

Thanks for your feedback.


	* reorg.c (fill_simple_delay_slots): Reindent block of code.
	* resource.c (mark_target_live_regs): Reformat conditional block.


-- 
Eric Botcazou
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.diff
Type: text/x-patch
Size: 4993 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130414/d9a0ba62/attachment.bin>


More information about the Gcc-patches mailing list