[llvm-dev] FMA canonicalization in IR

[Finkel, Hal J. via llvm-dev]

Sent from my Verizon Wireless 4G LTE DROID
On Nov 19, 2016 10:26 AM, Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>> wrote:
>
> If I have my FMA intrinsics story straight now (thanks for the explanation, Hal!), I think it raises another question about IR canonicalization (and may affect the proposed revision to IR FMF):

No, I think that we specifically don't want to canonicalize to fmuladd at the IR level at all. If the backend has the freedom to form FMAs as it sees fit, then we should delay the decision until whenever the backend finds most appropriate. Some backends, for example, form FMAs using the MachineCombiner pass which considers critical path, latency, throughputs, etc. in order to find the best fusion opportunities. We only use fmuladd when required to restrict the backend to certain choices due to source-language semantics.

Thanks again,
Hal

>
> define float @foo(float %a, float %b, float %c) {
>   %mul = fmul fast float %a, %b     ; using 'fast' because there is no 'fma' flag
>   %add = fadd fast float %mul, %c
>   ret float %add
> }
>
> Should this be:
>
> define float @goo(float %a, float %b, float %c) {
>   %maybe.fma<http://maybe.fma> = call fast float @llvm.fmuladd.f32(float %a, float %b, float %c)
>   ret float %maybe.fma<http://maybe.fma>
> }
> declare float @llvm.fmuladd.f32(float %a, float %b, float %c)
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161119/7e0a9d34/attachment.html>