<div dir="ltr"><div>Can we use the regular FP instructions (fadd, fmul, etc.) as a model?<br></div><div><br></div><div>If both operands to any of the binops are undef, then the result is undef. So for the corresponding constrained intrinsic, if both operands are undef, the result is undef and the exception state is also undef:</div><div><br></div><div>  %r = call float @llvm.experimental.constrained.fadd.f32(float undef, float undef, metadata !"round.dynamic", metadata !"fpexcept.strict")</div><div>  --></div><div>  %r = undef</div><div><br></div><div><div>  %r = call float @llvm.experimental.constrained.fadd.f32(float 
undef, float undef, metadata !"round.dynamic", metadata 
!"fpexcept.maytrap")</div><div>  --></div><div>  %r = undef</div><div><br></div></div><div><br></div><div>If one operand is undef and the other is regular value, assume that the undef value takes on some encoding of SNaN:</div><div><div><br></div><div>  %r = call float @llvm.experimental.constrained.fadd.f32(float 
undef, float %x, metadata !"round.dynamic", metadata 
!"fpexcept.strict")</div></div><div>  --></div><div><div><div>  %r = call float @llvm.experimental.constrained.fadd.f32(float SNaN, float %x, metadata !"round.dynamic", metadata 
!"fpexcept.strict") ; raise invalid op exception<br></div></div></div><div>  (%r could be folded to QNaN here, but we can't get rid of the call, so don't bother?)<br></div><div><br></div><div><div><div>  %r = call float @llvm.experimental.constrained.fadd.f32(float 
undef, float %x, metadata !"round.dynamic", metadata 
!"fpexcept.maytrap")</div></div><div>  --></div><div>  %r = QNaN ; exception state does not have to be preserved<br></div><div><br></div><div>Does that match the proposed behavior in <a href="https://reviews.llvm.org/D102673" target="_blank">https://reviews.llvm.org/D102673</a> <span><span>(cc @sepavloff)?</span></span></div><div><br></div><div>We could go further (potentially reduce to poison) if we have fast-math-flags on the calls -- just as we partially do with the regular instructions -- but it probably doesn't matter much to real code.<br></div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 9, 2021 at 12:06 PM Kevin Neal via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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">






<div>
<font size="2" face="Courier New"><span style="font-size:11pt">
<div>How should the constrained FP intrinsics behave when called with an operand that is “undef” and the FP environment is _<i>not</i>_ the default environment? I’m specifically working in the middle end passes if it matters. Let me start with the assumption
that the rounding mode is not relevant. That still leaves the exception handling as a factor:</div>
<div><font face="Calibri"> </font></div>
<div>With “fpexcept.maytrap” we are allowed to drop instructions that could or would cause a trap at run-time. Does this imply we can fold the entire instruction to a new undef?</div>
<div> </div>
<div>With “fpexcept.strict” we are _<i>not</i>_ allowed to lose or reorder traps. So how does that affect undef? What happens in the backend? Perhaps the middle end should leave the instruction with the undef and let the backend do something reasonable?</div>
<div> </div>
<div>The “maytrap” case is the one I’m most interested in. An earlier version of D103169 would fold away undef constrained intrinsics in the maytrap case. This was removed so it could be handled without affecting the rest of the patch I believe.</div>
<div><font face="Calibri"> </font></div>
<div>Opinions?</div>
<div><font size="2" face="Calibri"><span style="font-size:10pt">--<font size="2"><span style="font-size:11pt">
<br>

</span></font><font face="Courier New">Kevin P. Neal<br>

</font><font face="Courier New">SAS/C and SAS/C++ Compiler</font></span></font></div>
<div><font size="2"><span style="font-size:10pt">Compute Services</span></font></div>
<div><font size="2"><span style="font-size:10pt">SAS Institute, Inc.</span></font></div>
<div><font face="Calibri"> </font></div>
<div><font face="Calibri"> </font></div>
<div><font face="Calibri"> </font></div>
<div><font face="Calibri"> </font></div>
</span></font>
</div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>