https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513
--- Comment #21 from Oleg Endo <olegendo at gcc dot gnu.org> --- (In reply to Oleg Endo from comment #17) > > In the 'addsf3_i' pattern, I've tried replacing the > > (use (match_operand:PSI 3 "fpscr_operand" "c")) > > with > > (set (match_operand:PSI 3 "fpscr_operand" "=&c") > (unspec:PSI [(match_dup 3)] UNSPEC_FPSCR_SET))] > > > I haven't checked all the other side effects it could have, but at least the > FMA combine patterns still seem work after that change. With those changes above applied to all the other FP insns, the FMA tests in gcc.target/sh fail. One problem is that at -O1, FMA patterns won't be expanded initially, but are rather formed during combine. With the more complex FPSCA set/use combine won't match the patterns at -O1 but only at -O2. This is regression is probably acceptable. The other issue is that the fix for PR 56547 doesn't work anymore, because for some reason combine can't figure out what to do with the 1.0 constant. Probably because now it'd need to deal with multiple-set insns, which it doesn't do well. Adding a combine bridge pattern doesn't make it go further, as it won't try to combine 'fpreg = fpreg + 1.0' and 'fpreg = fpreg * fpreg'. In this case it's probably better to do a manual fma combine in the split1 pass. This is more effort, but would also fix the first problem.