[llvm-dev] Combining fast math flags with constrained intrinsics

[Serge Pavlov via llvm-dev]

One of the viewpoints on the constrained intrinsics is that it is a way to
represent floating point environment. In this case they are just variants
of corresponding IR nodes and in theory we could use the constrained
intrinsics everywhere instead of the regular nodes. From this viewpoint it
make sense to keep symmetry between constrained intrinsics and
corresponding regular IR nodes.

So for the first question the variant `a` (generate a constrained version
of the llvm.fmuladd instrinsic) looks preferable. Additional flags that
specify the way compiler should treat this node (like fast math flags)
should be applied to constrained intrinsics in the same extent as to the
non-constrained counterparts. Particular combination of a node and
additional flags may be treated differently for constrained intrinsics
depending on its semantics.

This symmetry could help us in implementing full-fledged support of the
constrained intrinsics in transformation - they would share the same code
path with corresponding non-constrained nodes.

Thanks,
--Serge


On Sat, Jan 18, 2020 at 10:25 PM Cameron McInally <cameron.mcinally at nyu.edu>
wrote:

> On Fri, Jan 17, 2020 at 8:09 PM Finkel, Hal J. <hfinkel at anl.gov> wrote:
> > Andy, thanks for writing this up. A few thoughts:
> >
> >  1. The mental model that I have is that there is always an FP_CONTRACT
> pragma: there's some default (implicit) pragma at the beginning, and what
> it says (off/on/fast) is controlled by the command-line flags (or the
> driver's default if no flags are explicitly provided). Thus, unless there's
> some reason my model doesn't really work, I lead against differentiating
> between the there-is-a-pragma and there-is-not-a-pragma cases in some
> fundamental way.
> >
> >  2. I'm inclined to go with your choice (b) above because I think that
> we should treat these concepts as orthogonal
>
> Agreed.
>
> > (to the extent that is reasonable: by design, we don't want to
> reassociate constrained operations, so that flag just might have on effect
> on those intrinsics). This lets the later optimization passes decide how to
> treat the various combinations of flags and intrinsics (just as with all
> other intrinsics that might be present).
>
> I think I agree, but this needs clarification. My view is that we
> don't want to reassociate constrained operations when
> `-fp-model=strict`. When `-fp-model=fast`, we should reassociate and
> do pretty much all the reasonably safe FMF transformations, with the
> caveat that I don't think NNAN and NINF make sense for any trap-safe
> mode. We may want to trap on those NaNs and Infs we'd optimize away.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200120/e3a8d54c/attachment.html>