On 09/14/2016 07:04 AM, Segher Boessenkool wrote:
I'd
probably start by fixing the dataflow issues and see if that fixes the
regrename thing as a side effect.
Have you seen https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00091.html ?
I missed it. My interpretation....
The uses at each "strange" exit fixing the first issue with
shrink-wrapping definitely sounds like we've got a dataflow problem of
some sort.
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.
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.
By deferring that step until after prologue/epilogue generation we
shouldn't cause unnecessary register saves/restores.
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.
Bernd knows the regrename code better than anyone. Is there any way the
two of you could work together to try and track down what's going on in
the hash_map_rand case? Even throwing in some more debug stuff might
help narrow things down since it's renaming something to a non-volatile,
non-separately shrink wrapped register that's causing problems.
I think enabling regrename by default is the right thing to do long term.
Then rs6000 (and many other ports probably) will just turn it off again.
It is actively harmful.
I think you're over stating things here.
Can we agree that there's a set of targets that will improve and a set
that are harmed? And that to enable regrename by default we need to
either better describe the pipeline characteristics we're optimizing for
or a well defined way for targets to turn it off?
jeff
