search for: fpcontract

...saw a behavior that doesn't look right. I think its a bug in the PPC backend. The 32-bit PPC .td file defines a pattern for the fnmsubs instruction like this: def : Pat<(fsub F4RC:$B, (fmul F4RC:$A, F4RC:$C)), (FNMSUBS F4RC:$A, F4RC:$C, F4RC:$B)>, Requires<[FPContractions]>; The unique feature of this parttern is that it maps a pair of LLVM IR instructions into a single PPC instruction. def FNMSUBS : AForm_1<59, 30,(outs F4RC:$FRT), (ins F4RC:$FRA, F4RC:$FRC, F4RC:$FRB), "fnmsubs $FRT, $FRA, $FRC, $FRB", FPGeneral,...

...onor‑nans, or somesuch), the re-association isn’t allowed, and that blocks the madd contraction. >> >> I agree. FP contraction alone only allows us to do x*y+z -> fma(x,y,z). > > > I agree too, but the more difficult question is "which flags are needed here?” > Would FPContract + no-inf be enough? If not why and how to document it? I think that the relevant question is: Is the contracted form more precise for all inputs (or the same precision as the original)? If so, then this should be allowed with just fp-contract+no-inf. Otherwise, more is required. -Hal > > &...

...t; > >> I agree. FP contraction alone only allows us to do x*y+z -> > > >> fma(x,y,z). > > > > > > > > > > > > I agree too, but the more difficult question is "which flags are > > > needed here?” > > > > Would FPContract + no-inf be enough? If not why and how to > > > document > > > it? > > > I think that the relevant question is: Is the contracted form more > > precise for all inputs (or the same precision as the original)? If > > so, then this should be allowed with just f...