API break for out-of-tree targets implementing TargetLoweringBase::isFMAFasterThanMulAndAdd

Hello,

To any out-of-tree targets, please be aware that I intend to commit a
patch that will break the build of any target implementing
TargetLoweringBase::isFMAFasterThanMulAndAdd, for the reasons
described below. (Basically, the current interface definition is
broken and not followed, and no in-tree target was doing the right
thing with it, so it is unlikely any out-of-tree target is either...)

To un-break your build after this patch goes through, you will need to
rename isFMAFasterThanMulAndAdd to isFMAFasterThanFMulAndFAdd and
ensure that it returns true for any type that eventually legalizes to
a type for which FMAs are faster than FMul + FAdd (which usually means
you have hardware support of the operation.). You can look at in-tree
target implementations as an example.

Please let me know if there are any objections before tomorrow morning.

Stephen

fma-faster-check-types.patch (26.2 KB)

OK, the patch is committed as r185956, and is guaranteed to break
either the merge or build of any out-of-tree target implementing
TargetLoweringBase::isFMAFasterThanMulAndAdd.

To resolve, rename isFMAFasterThanMulAndAdd to
isFMAFasterThanFMulAndFAdd and ensure that it returns true for any
type that eventually legalizes to a type for which FMAs are faster
than FMul + FAdd. For all in-tree targets, this simply requires
checking any subtarget prerequisites (if any) and then checking the
scalar type of the EVT passed to the function...however, it may be
more complicated in other situations (for example, if FMAs are
supported on a scalar type but not on a legal vectorized type, and the
fmul + fadd on the vector is faster than scalarizing and using the
scalar FMA...)

Please let me know if there any questions or concerns.
Stephen