On Fri, Mar 04, 2016 at 06:39:54PM +0100, Bernd Schmidt wrote: > I've managed to reproduce this, and I think your analysis of the problem is > correct. So the patch is probably ok from the point of you of "will it > work". I can probably be convinced to approve it as-is, but I wonder if > you'd be prepared to try something else first. > > This whole area in IRA is turning into spaghetti a little bit. I would > prefer that we schedule a new small optimization pass beforehand (either as > a real pass or just a function call) that does only the label-substituting > trick from update_equiv_regs, then removes dead code as necessary. When we > then get to IRA and setting up equiv regs, we should no longer get to a > point where we need to reverify equivalences or update regstat.
I had the same thought myself, but wondered what I'd be getting into so didn't mention the idea. ;-) I'll have a go. (Not sure if I'd trust me to get it right though, for stage 4.) Something for later: It seems to my untrained eye that more than just the label substitution should be separated out. All of the latter half of update_equiv_regs doing global combine and moving insns could be better separated from the rest of ira. It is to some extent, by use of reg_equiv[] vs. ira_reg_equiv[], but shares the REG_EQUIV notes. That means the REG_EQUIV notes created by ira need to take into account ira, lra and reload behaviour and are thus rather more restrictive than needed for the mini-combine pass. eg. See the comment about calls in validate_equiv_mem. Incidentally, an all-langs bootstrap and regression test of gcc triggers delete_unreachable_blocks just once for x86_64 and never for powerpc64le. The file is testsuite/gfortran.dg/pr46755.f, which of course isn't that surprising since the pr46755 fix added the delete_unreachable_blocks call. -- Alan Modra Australia Development Lab, IBM
