<div dir="ltr"><div dir="ltr">On Fri, 29 Oct 2021 at 21:51, Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-6952061586146863985WordSection1">
<p class="MsoNormal">> Finally, I think we need to separate the IR from DAG/MIR behaviour. It seems to me that the target option is what overrides the behaviour, not function/module options, so we should worry about the targets' behaviour, not at which level
 the flag is<br></p><p class="MsoNormal"><u></u></p>
<p class="MsoNormal"><u></u>  </p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-6952061586146863985WordSection1"><p class="MsoNormal">I don’t know what you’re saying here. What do you mean by “we should worry about the targets' behaviour”? If the IR says fp-contract is not allowed for a given instruction, why should the target options be allowed to overrule that?</p></div></div></blockquote><div><br></div><div>They shouldn't. Unless it's a hardware-specific design issue (ex. there is no fused op, or there is no un-fused op), but that should be done at the DAG level, I think, not IR level.</div><div><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 lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-6952061586146863985WordSection1"><p class="MsoNormal"></p><p class="MsoNormal"><u></u></p>
<p class="MsoNormal">Two notes, however:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="gmail-m_-6952061586146863985MsoListParagraph" style="margin-left:0in">resetTargetOptions doesn’t handle the AllowFPOpFusion setting (as far as I can tell, there is no corresponding function attribute)<u></u><u></u></li><li class="gmail-m_-6952061586146863985MsoListParagraph" style="margin-left:0in">There is a comment for resetTargetOptions which says this:<u></u><u></u></li></ol>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-size:10pt;font-family:"Courier New"">// FIXME: This function needs to go away for a number of reasons:<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-size:10pt;font-family:"Courier New"">// a) global state on the TargetMachine is terrible in general,<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-size:10pt;font-family:"Courier New"">// b) these target options should be passed only on the function<u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:0.5in"><span style="font-size:10pt;font-family:"Courier New"">//    and not on the TargetMachine (via TargetOptions) at all.<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">As you may guess, I completely agree with the comment. FWIW, this comment was added by Eric Christopher in 2015 (<a href="https://github.com/llvm/llvm-project/commit/35a8a62125ccfa0ef804584738a295ed5c17750f" target="_blank">https://github.com/llvm/llvm-project/commit/35a8a62125ccfa0ef804584738a295ed5c17750f</a>).</p></div></div></blockquote><div><br></div><div>I think the biggest problem there is that this is a target flag not an IR flag and that's not a good design. I completely agree with the comment also.</div><div><br></div><div>I also agree the dance of inst/func/mod level flags isn't trivial and it a source of at least confusion, but potentially bugs.</div><div><br></div><div>I also want to clarify what I meant for "perfectly valid", and that was "it solves the problem and is technically doable". I didn't want to imply it was good or there wasn't a better way of doing it.</div><div><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 lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-6952061586146863985WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal">The core of my complaint about the current state of things is that the backend is treating the fast-math flags as if they are “on or undecided” rather than “on or off.” IMO, the absence of a fast-math flag in the IR means that the behavior
 controlled by that flag is not permitted. That’s the way the IR is treated in IR-level optimization passes, but the backend codegen (at least in places) behaves as though the absence of a fast-math flag means “not permitted unless enabled by TargetOptions.”
 That’s bad as a starting point, but it’s particularly bad when you start linking together IR from multiple modules that may have been created from different compilation units with different options.</p></div></div></blockquote><div><br></div><div>I absolutely agree with you. That's why I've added Sebastian, who worked on a very similar problem not long ago. I myself have fixed similar problems in the Arm backend a long time ago.</div><div><br></div><div>I think we really should treat the lack of fast-math-like flags to mean their behaviour is *forbidden*, and force front-ends and middle-end passes to add them if the user requested / allowed.</div><div><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 lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-6952061586146863985WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u>I’d also like to make one thing explicit. While the change I’m proposing would change the behavior of the backend for all front ends, it wouldn’t “break” them in the sense of producing incorrect results. When TargetOptions::AllowFPOpFusion==FPOpFusionMode::Fast
 the backend is *<b>allowed</b>* to fuse operations, but it isn’t required or guaranteed to fuse them. With the change I am proposing, the backend wouldn’t form fuse FP options unless the ‘contract’ flag were set, but that wouldn’t lead to incorrect results.
 It would lead to lost performance in some cases, but I think that can be recovered by generating IR with the semantics that were intended. Similarly, for the other fast-math flags. However, I will admit that it could be an uncomfortable transition for some
 front ends.</p></div></div></blockquote><div><br></div><div>It's not that simple. We want to keep the performance for existing code with existing compilation infrastructure as much as possible.</div><div><br></div><div>When an existing project with its existing compilation flags use a new version of clang and suddenly the performance is considerably lower, they may start to look for things to change or may just blame on "new compiler" and try other compilers, or worse, get stuck with an old version of clang.</div><div><br></div><div>But this is also not a huge deal, and we can fix that with more clear communication...</div><div><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 lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-6952061586146863985WordSection1"><p class="MsoNormal"><u></u></p>
<p class="MsoNormal">Regarding bloating the IR, I’m not sure if this is a theoretical problem or real one. The bitcode writer will emit a byte for the fast-math flags if any are set for each call or FP operation, and if none are set it will not emit that byte.
 For clang, this is a non-issue because clang always sets the fast-math flags on the individual operations. It’s at least theoretically possible that there is some front end that never sets the fast-math flags and relies on the global setting. In that case,
 adding the fast-math flags would bloat the IR considerably. For most of the FMF, omitting the flags would cause considerable missed optimization opportunities in the middle end, but the ‘contract’ flag is a bit of a special case because it isn’t typically
 used at all before codegen.</p></div></div></blockquote><div><br></div><div><div>My comment on the increase in size was meant as a check, not as a blocker. It could be well within noise levels and totally worth the change.</div><div><br></div></div><div>cheers,</div><div>--renato</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-6952061586146863985WordSection1"><div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
</blockquote>
</div>
</div>
</div>

</blockquote></div></div>