On 05/08/2015 02:14 PM, Segher Boessenkool wrote:
> "Cleaner"? In this code? Heh.
Heh.
> use_crosses_set_p often estimates pessimistically. Is that what is
> happening here? Using real dataflow in combine would fix that (and many
> other problems). Not that that helps you right now ;-)
Yes, I think so. Proper data flow would fix this. But...
My thought is that the use_crosses_set_p could grow another parameter,
ignore_luid, so that if it matches DF_INSN_LUID (rsp->last_set) we don't fail
the test.
Then can_combine_p has to adjust its use like so:
use_crosses_set_p (src, DF_INSN_LUID (insn),
succ ? DF_INSN_LUID (succ) : -1)
which at least handles the 3-insn combine case, if not the 4-insn combine case.
I'll try out both this and Law's set_noop_p suggestion soon.
r~
