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

Wed Apr 17 01:57:50 PDT 2019

simoll added a comment.

In D57504#1469354 <https://reviews.llvm.org/D57504#1469354>, @hsaito wrote:

> In D57504#1468510 <https://reviews.llvm.org/D57504#1468510>, @simoll wrote:
>
> >   1. Updates
> > - added constrained fp intrinsics (IR level only).
> > - initial support for mapping `llvm.experimental.constrained.*` intrinsics to `llvm.vp.constrained.*`.
>
>
> Do we really need both vp.fadd() and vp.constrained.fadd()? Can't we just use the latter with rmInvalid/ebInvalid? That should prevent vp.constrained.fadd from losing optimizations w/o good reasons.

According to the LLVM langref, `"fpexcept.ignore"` seems to be the right option for exceptions whereas there is no `"round.permissive"` option for the rounding behavior. Abusing rmInvalid/ebInvalid seems hacky.

> Do we have enough upside in having both?

I see no harm in having both since we already add the infrastructure in LLVM-VP to abstract away from specific instructions and/or intrinsics. Once (if ever) exception, rounding mode become available for native instructions (or can be an optional tag-on like fast-math flags), we can deprecate //all// constrained intrinsics and use `llvm.vp.fdiv`, etc or native instructions instead.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D57504