<div dir="ltr"><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Thanks,<br>--Serge<br></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 29, 2021 at 7:23 AM Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</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 lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_8929104815710529489WordSection1">
<p class="MsoNormal">That brings me to the RFC part of my message. I’d like to start updating the backend so that it doesn’t do things like this. As a general principle, I would say, “All semantics must be represented in the IR and the backend must respect
 the IR semantics.” And a corollary: “Anything which can be represented at the instruction level must be represented at the instruction level.” This corollary would eliminate potential conflicts between function attributes (like "unsafe-fp-math") and individual
 IR instructions.<br></p></div></div></blockquote><div> </div><div>From the viewpoint of optimization, it is important to allow internal representation in which different instructions may have different properties including fast-math flags. The proposed general principle looks very attractive, as it leads to flexible representation, which is also can be safer as properties are queried from instruction only and not a combination instruction+function+module.<br><br>It is not mandatory to keep flags in the instruction, maybe an instruction method that returns a set of flags would be sufficient. Such a method would calculate the flags if they are not kept in instruction. It could help solving problems like <a href="https://llvm.org/PR52259">https://llvm.org/PR52259</a>, as having fast-math flags on instructions like phi or select (and probably some others) does not look natural. <br></div><div><br></div><div>Thanks,</div><div>--Serge</div></div></div>