<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
/* Style Definitions */
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:blue;
text-decoration:underline;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle21
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I would also expect/hope fast-math to work the same way. <o:p>
</o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As far as GCC compat, I know we play a little fast/loose with it in other cases, but I can definitely see the danger here. To me, this feels like “GCC made a bad choice, so we are sticking ourselves with it”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Steve (Numerics) Canon <scanon@apple.com> <br>
<b>Sent:</b> Wednesday, June 30, 2021 10:40 AM<br>
<b>To:</b> Stephen Canon <scanon@apple.com><br>
<b>Cc:</b> Keane, Erich <erich.keane@intel.com>; Yaxun Liu <yaxun.liu@amd.com>; llvm-dev@lists.llvm.org; cfe-dev@lists.llvm.org; guille@berkeley.edu<br>
<b>Subject:</b> Re: [llvm-dev] fp-contract=fast and pragmas<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Note that I’m actually pretty sympathetic to this line of argument; compilation-unit scoped flags are too heavy-handed, and pragma and attribute scoping is much nicer. I just think that it’s a much broader change than this one flag and
requires a correspondingly broader discussion. E.g. I would expect fast-math to behave identically. It would also, as John noted, introduce a subtle incompatibility with GCC, which would be pretty dangerous.<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">– Steve<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jun 30, 2021, at 1:34 PM, Steve (Numerics) Canon via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Aren’t you all (Intel) the ones promoting -f(no-)protect-parens, which is a command line flag that overrides source code semantics in _exactly_ the same manner?<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">– Steve<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jun 30, 2021, at 1:30 PM, Keane, Erich <<a href="mailto:erich.keane@intel.com">erich.keane@intel.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">It seems awkward to me that we have a command-line switch that overrides source code to this extent. Typically our command-line arguments cause us to change ‘defaults’, rarely do they cause us to ignore the source code. IMO, there is
a bit of a natural ‘order’ to where how an option like this should be specified, that is, code overrides command line overrides default.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">At bare minimum, having a pragma like this that is supported, but just ignored in this case needs to have some level of diagnostic. Silently ignoring a developer’s preference is the worst thing we can do.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<div>
<p class="MsoNormal"><b>From:</b><span class="apple-converted-space"> </span>Steve (Numerics) Canon <<a href="mailto:scanon@apple.com">scanon@apple.com</a>><span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Wednesday, June 30, 2021 10:20 AM<br>
<b>To:</b><span class="apple-converted-space"> </span>Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span>John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>>;
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>; <a href="mailto:cfe-dev@lists.llvm.org">
cfe-dev@lists.llvm.org</a>; Yaxun Liu <<a href="mailto:yaxun.liu@amd.com">yaxun.liu@amd.com</a>>; Keane, Erich <<a href="mailto:erich.keane@intel.com">erich.keane@intel.com</a>>; Blower, Melanie I <<a href="mailto:melanie.blower@intel.com">melanie.blower@intel.com</a>>;
Sanjay Patel <<a href="mailto:spatel@rotateright.com">spatel@rotateright.com</a>>; Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@gmail.com</a>>; Hal Finkel <<a href="mailto:hal.finkel.llvm@gmail.com">hal.finkel.llvm@gmail.com</a>>;
<a href="mailto:guille@berkeley.edu">guille@berkeley.edu</a>; <a href="mailto:ueno.masakazu@jp.fujitsu.com">
ueno.masakazu@jp.fujitsu.com</a>; <a href="mailto:Matthew.Arsenault@amd.com">Matthew.Arsenault@amd.com</a><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: fp-contract=fast and pragmas<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It sounds to me like this test is simply incompatible with fp-contract=fast and should not be used in that mode.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">– Steve<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">On Jun 30, 2021, at 11:14 AM, Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com">andrew.kaylor@intel.com</a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Hi John,<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Let me be clarify that ICC-compatibility isn’t my goal here. We can do that out-of-tree for Intel compilers based on LLVM.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">My motivation is a problem I’m working on with the LLVM test suite. The Polybench benchmarks in the test are currently attempting to use ‘#pragma STDC FP_CONTRACT OFF’ to create a value-safe kernel whose results can be compared against
an otherwise identical kernel that is compiled with whatever options the test suite is configured to use. This strategy fails if the test suite is configured to compile with ‘-ffp-contract=fast’. That’s the problem I’m trying to solve by having clang respect
the pragma.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">See<span class="apple-converted-space"> </span><a href="https://reviews.llvm.org/D25346">https://reviews.llvm.org/D25346</a>,<span class="apple-converted-space"> </span><a href="https://reviews.llvm.org/D102861">https://reviews.llvm.org/D102861</a>,
and<span class="apple-converted-space"> </span><a href="https://reviews.llvm.org/D104935">https://reviews.llvm.org/D104935</a>.<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>