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

[Hideki Saito via Phabricator via llvm-commits]

hsaito added a comment.

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

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


Then, please propose one more rounding mode, like round.permissive or round.any.

In D57504#1470254 <https://reviews.llvm.org/D57504#1470254>, @hfinkel wrote:

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


Yep. If one additional generally-useful rounding mode gets rid of several partially redundant intrinsics, that would be a good trade-off.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57504