On Wed, Jun 08, 2016 at 06:43:23PM +0200, Bernd Schmidt wrote: > On 06/08/2016 05:16 PM, Segher Boessenkool wrote: > >On the plus side I should have caught most of it now. And the failures > >are rarely silent, they show up during compilation already. > > That does count as a plus. Aborts in dwarf2cfi, I assume.
Yeah. > >Most of the problems are code changes the later passes want to do that > >are valid an sich but that dwarf2cfi does not like, like not restoring > >a callee-saved register before a noreturn call. Those later patches > >already know not to touch epilogue instructions, but only for the single > >epilogue, not for instructions scattered throughout the whole function. > > Yeah, that's a problem though - having to disable otherwise valid > transformations is always a source of errors. Ideally we would be able to e.g. dead-code delete frame restores and not have dwarf2cfi throw fits. I'm not certain we can always express that in the CFI though (two paths joining at the same block, having different locations for the saved registers -- one restored and one not). Maybe we could just say a register is restored even when it's not, but that seems very fragile. One thing I should try is put a USE of the saved registers at such exits, maybe that helps those passes that now delete frame restores to not do that. > Is there a strong reason to keep thread_p_e_insns at its current > position in the compilation process, or could it be moved later to > expose this problem to fewer passes? peephole2, bbro, split4/5, sched2 should stay later. It seems reasonable we still want some dce/dse there. rnreg needs to be late, too; maybe not that late though. Dunno about cprop_hardreg, but I guess it wants to be after peep2. > >There is no standard naming for this as far as I know. I'll gladly > >use a better name anyone comes up with. > > Maybe just subpart? That is maybe just a bit too generic. Naming, such a hard problem :-) Segher
