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.
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.
I continue to wonder if we could add something similar to
CALL_INSN_FUNCTION_USAGE where we attach uses for all the call-saved
registers onto a return insn. We would attach them at the end of
prologue/epilogue generation and only attach those where were live
somewhere in the code.
Maybe adding the new insns to the {pro,epi}logue_insn_hash will help
something. Or maybe it will blow up spectacularly. Will know in a
bit.
I think that'll resolve the sel-sched issue, but I doubt the rest.
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.
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.
Jeff
