<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Generally, this makes a lot of sense to me. If we have semantics
expressible in IR, we should use that as the source of truth. Not
really my area, so I don't have any opinion on the specific
implementation plan. <br>
</p>
<p>Philip<br>
</p>
<div class="moz-cite-prefix">On 10/28/21 5:22 PM, Kaylor, Andrew via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SJ0PR11MB5646B90B61315578CBE41209E8879@SJ0PR11MB5646.namprd11.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hi everyone,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is related to the recent thread about
fp-contract and front end pragma controls, but I want to
generalize the discussion in terms of how the
target-independent codegen in the backend is implemented.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Until sometime in 2017 (I think) the
fast-math flags were not passed through to the Selection DAG,
and so the only ways to control floating-point behavior were
through settings in the TargetOptions or by settings function
attributes. Since 2017, however, the fast-math flags have been
attached to floating-point nodes in the selection DAG. This
leads to some ambiguous situations where the TargetOptions or
function attributes can override the absence of fast-math
flags on individual nodes. An example of this is the
fp-contract setting. If a source file is compiled with clang
using the ‘-ffp-contract=fast’ setting but the file contains
either “#pragma STDC FP_CONTRACT OFF” or “#pragma clang fp
contract(off)” the front end will generate IR without the
‘contract’ fast-math flag set, but the X86 backend will
generate an FMA instruction anyway.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a href="https://godbolt.org/z/dov6EcE8G"
moz-do-not-send="true">https://godbolt.org/z/dov6EcE8G</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is particularly bad in the case of
CUDA, because CUDA uses fp-contract=fast by default. So, the
user’s code can explicitly say “don’t generate fma here” and
the compiler will respond, “meh, I think I will anyway.”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a href="https://godbolt.org/z/c4h1nK9M3"
moz-do-not-send="true">https://godbolt.org/z/c4h1nK9M3</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There are other cases where the backend
code will check for TargetOption::UnsafeFPMath for things like
reassociation that can be represented using fast-math flags.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As a first step toward this goal, I’ve
prepared a patch which closes the back door for fp-contract
control.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a href="https://reviews.llvm.org/D112760"
moz-do-not-send="true">https://reviews.llvm.org/D112760</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This patch is currently incomplete, in as
much as I didn’t update failing tests for several target
architectures. I did update the X86 and AMDGPU tests to
provide examples of how they can be made to work. I will fix
the rest if we decide this is the correct direction. There is
a failing CUDA test in the clang front end that I think will
require a different approach involving some driver changes to
get clang to generate IR for the semantics it intends rather
than setting an option and counting on the backend to
disregard the IR.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks in advance for any feedback!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Andy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</body>
</html>