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

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In D57504#1469847 <https://reviews.llvm.org/D57504#1469847>, @simoll wrote:

> 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.


There is an indirect harm in adding more intrinsics with partially-redundant semantics: writing transformations and analyses requires logic that handles both forms. I recommend having fewer intrinsics where we can have fewer intrinsics.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57504