[llvm-dev] Fusing contract fadd/fsub with normal fmul

Sanjay Patel via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 12 06:40:15 PDT 2017

For reference, the FMF 'contract' patches are listed here:

If we can make the documentation better, that would certainly be a welcome

It would be better to see the IR for your example(s), but I think you'd
need 'contract' on both the fmul and fadd to generate an FMA.
Conservatively, we wouldn't alter the result if either component somehow
required strict FP. To vectorize, you probably need 'fast' on both ops
because vectorization would be changing the order of operations

On Fri, Jun 9, 2017 at 9:04 PM, Yichao Yu via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
> On LLVM 5.0 (current trunk), fadd/fsub and fmul that are both marked
> with `contract` or `fast` can be merged to a fma instruction by the
> backend.
> I'm wondering about the exact semantic of this new flag as well as
> `fast` and in particular, would it be valid to do this when only the
> `fadd`/`fsub` (and not the `fmul`) is marked with `contract` or at
> least `fast`. The reasoning is that doing this will have a similar
> effect as if the `fadd`/`fsub` is performed not to IEEE spec so a
> single flag on this instruction should be enough for the
> transformation.
> The particular case I'm interested in is vectorized loop with
> reduction like in pseudo C code `s += a[i] * b[i]`. Our front end will
> recognize this and mark the `+` as `fast` to enable vectorization.
> It'll be great if this can enable the reduction to be done with `fma`
> instructions.
> Yichao Yu
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170612/da4be716/attachment.html>

More information about the llvm-dev mailing list