[PATCH] D57504: RFC: Prototype & Roadmap for vector predication in LLVM

Wed Oct 30 01:35:35 PDT 2019

simoll added a comment.

In D57504#1726355 <https://reviews.llvm.org/D57504#1726355>, @andrew.w.kaylor wrote:

> In D57504#1725554 <https://reviews.llvm.org/D57504#1725554>, @simoll wrote:
>
> >   1. Observations
> > - When using `fpexcept.ignore`, the fp callsites should have the `readnone` attribute set on them to override the `inaccessiblememonly` of the intrinsic declarations. That way DCE still works.
>
>
> Wouldn't that allow the call to be moved relative to other calls? Specifically, we need to make sure intrinsics aren't moved relative to calls that change the rounding mode. The "inaccessiblememonly" attribute is meant to model both the reading of control modes and the possible setting of status flags or raising of exceptions"
>
> > - The rules for constrained fp (`strictfp` on the function definition, only constrained fp in that function) apply only if there is a single fp op with exceptions in the function. That is `strictfp` is not necessary when all fp ops have `fpexcept.ignore`.
>
> I don't think this is right. Even if there are no constrained FP operations in the function we might have math library calls for which the strictfp attribute is needed to prevent libcall simplification and constant folding that might violate the rounding mode.

I see. Since we need to model the default fp environment with these intrinsics (and this is our priority), let me make the following suggestion: VP intrinsics will have a rounding mode and exception behavior argument from the start but the only allowed values are "round.tonearest" and "fpexcept.ignore". Once we have a solution for the general case implemented for constraint fp, we will unlock that feature also for LLVM VP.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57504/new/

https://reviews.llvm.org/D57504