On Tue, Dec 13, 2016 at 10:05:58AM +0100, Richard Biener wrote:
> > The following patch just throws away expressions that have 32 register
> > references in there, I think that is so huge that it will be really very
> > unlikely to be beneficial in the debug info and var-tracking would likely
> > throw it away anyway. Or shall I use some --param instead of the constant
> > (any suggestions on how to call it)? Another option (with or without param)
> > is to create debug temporaries in those cases and split the expression into
> > smaller expressions. Not sure if it is worth it though.
>
> Hmm, so the "easier" fix would be to always create a debug insn
> right after INSN setting a new debug reg to SRC and then doing the
> replacement with the new debug reg? With the "optimization"
Well, that would IMHO kill the simplification effect of the combiner
for debug insn, nothing would be simplified in debug insns anymore.
But perhaps we can try to simplify and after simplification using
some metrics compare if the new expression is more complex than before or
not. If it is more complex, then (if not emitted already) emit the extra
debug insn with a debug temp (next to the insn being removed, aka insn -
first argument to propage_for_debug) and replace again from DEST to the debug
temp.
so it means we will often create uselessly large debug info.
> The to not do that for some single use and/or "simple" SRC cases
> (I think "simple" SRC would be sth with a single/zero register reference).
But simplify-rtx will often do something even for the more complex SRC
cases.
> You are fixing it at the wrong end IMHO, by throwing away the
> thing after propagating (and doing all the work and doing the
> check on each individual propagation result).
Jakub
