<div dir="ltr">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.<br><br>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.<div><br></div><div>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. <br><div><br><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Thanks,<br>--Serge<br></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 18, 2020 at 10:25 PM Cameron McInally <<a href="mailto:cameron.mcinally@nyu.edu">cameron.mcinally@nyu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jan 17, 2020 at 8:09 PM Finkel, Hal J. <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>
> Andy, thanks for writing this up. A few thoughts:<br>
><br>
>  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.<br>
><br>
>  2. I'm inclined to go with your choice (b) above because I think that we should treat these concepts as orthogonal<br>
<br>
Agreed.<br>
<br>
> (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).<br>
<br>
I think I agree, but this needs clarification. My view is that we<br>
don't want to reassociate constrained operations when<br>
`-fp-model=strict`. When `-fp-model=fast`, we should reassociate and<br>
do pretty much all the reasonably safe FMF transformations, with the<br>
caveat that I don't think NNAN and NINF make sense for any trap-safe<br>
mode. We may want to trap on those NaNs and Infs we'd optimize away.<br>
</blockquote></div>