On Wed, Sep 14, 2016 at 01:33:04PM -0600, Jeff Law wrote: > On 09/14/2016 01:03 PM, Segher Boessenkool wrote: > >>If you think about it, conceptually we want the return insn to make the > >>callee saved registers "used" so that DCE, regrename and friends don't > >>muck with them. The fact that we don't is as much never having to care > >>all that much until recently. > > > >(There is no return insn at those exits; these are exits *without* > >successor block, not the exit block). > Ugh. Anywhere we could attach this stuff in the insn chain? If not, > the DF side of this problem gets uglier.
I put the USEs at the start of that noreturn basic block. > >It is puzzling to me why adding USEs for just the registers that *are* > >separately shrink-wrapped does not work; only all those that *could* be > >shrink-wrapped does. Do you have any idea about that? > Nope. No clue on that one. It almost seems like a book-keeping error > somewhere. Right. > >>I pondered just doing it for the separately wrapped components on that > >>particular path, but I've yet to convince myself that's actually correct. > > > >If that is not correct, how is the status quo correct? That is what > >puzzles me above, too. > I couldn't convince myself that we could trivially find all the > separately wrapped components on a particular path -- ie, we may have > had components saved/restored in some sub-graph. If an exit point from > the function is reachable from that sub-graph, then we need to make sure > any components from the subgraph are marked as live in addition to those > which are restored on the exit path. > > While it is just a reachability problem, I don't think we need to solve > it if we mark anything that was separately shrink wrapped as live at all > the exit points. Agreed, but why does it work if not separately shrink-wrapping anything? And why does it break on things that are *not* separately wrapped *anywhere*? > >There is a well-defined way to turn it off, via common/config/*/*-common.c > >, > >TARGET_OPTION_OPTIMIZATION_TABLE. We disagree on whether most targets will > >want it enabled, i.e. whether it should (eventually) be enabled by default. > I'm aware of TARGET_OPTION_OPTIMIZATION_TABLE -- I was thinking more > along the lines of trying to describe the conditions under which it is > not profitable and expose that. TARGET_OPTION_OPTIMIZATION_TABLE is a > lame way to attack this problem. Better than a target macro ;-) Segher
