On 16/11/16 13:10, Michael Meissner wrote:
Yeah, SFmode and DFmode should not have the TARGET_{S,D}F_FPR checks.
So, I can safely resolve my initial problem by simply removing them? And
that wouldn't break the other use of that predicate?
But a secondary problem is the early clobber in the match_scratch.
So, the FPR_FUSION insn works because operands 1 and 2 cannot conflict,
which means the early-clobber is not necessary, but the GPR_FUSION insn
cannot work because there's no way to ensure that operands 1 and 2 don't
conflict without also specifying that operands 0 and 2 don't conflict,
which they commonly do.
We could fix it, for now, by adding new patterns that fit both cases
(given that the register numbers are known at peephole time).
Or, we could disable the peephole in the case where this would occur (as
my original patch does, albeit bluntly).
Or, something else?
Andrew
