qiucf added a comment.
In D116015#3203067 <https://reviews.llvm.org/D116015#3203067>, @nemanjai wrote:
> Converting more generic code to target-specific intrinsics is sometimes
> necessary to ensure the generic IR doesn't get transformed in a way that is
> disadvantageous. I believe that the description of this review claims that to
> be the case for these negated FMA's. The obvious disadvantage of producing
> target-specific intrinsics is that the optimizer knows nothing about them so
> no advantageous transformations can happen either (i.e. hiding the semantics
> from the optimizer is sometimes a good thing and sometimes a bad thing).
>
> The description of this patch includes no test case that shows the optimizer
> performing an undesirable transformation. So the motivation for making the
> front end produce more opaque code is not at all clear.
Here's a pretty simple case: `vector float foo(vector float a, vector float b,
vector float c, vector float d) { return __builtin_vsx_xvnmsubasp(c, d, a*b); }`
It current produces `xvnegsp+xvmulsp+xvnmaddasp`, after this patch it produces
`xvmulsp+xvnmsubasp`. In some complicated cases, we can see much more
unexpected instructions generated.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D116015/new/
https://reviews.llvm.org/D116015
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
