<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=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Courier New";
color:#44546A;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.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"><span style="font-family:"Courier New";color:#44546A">Correct. You do need to add the required support to your backend.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">The X86, PowerPC, and SystemZ backends have basically complete support.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">The PowerPC backend has a fix to not reschedule floating-point instructions<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">around function calls if the rounding mode may change. I haven't heard<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">that the other two have this fix. AArch64 and RISC-V support are both a<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">work in progress so one of the three fully-supported targets is best to<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">examine and emulate.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">Also be aware that optimization of strict floating-point is a work in<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">progress, so be prepared for not-so-great performance.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">Lastly, there's currently no way to have machine-specific llvm intrinsics<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">respect "strict" mode. A fix has been proposed, but I don't think anything<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">has been implemented.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">It might have been clang 12 where a warning was introduced that told you<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">that "strict" floating-point doesn't work for that target and is therefore<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A">disabled. I don't remember exactly which release first had this.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:#44546A">--</span><span style="color:#44546A">
<br>
</span><span style="font-size:10.0pt;font-family:"Courier New";color:#44546A">Kevin P. Neal</span><span style="color:#44546A"><br>
</span><span style="font-size:10.0pt;font-family:"Courier New";color:#44546A">SAS/C and SAS/C++ Compiler<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:#44546A">Compute Services<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New";color:#44546A">SAS Institute, Inc.</span><span style="color:#44546A"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#44546A"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Cyril Six via llvm-dev<br>
<b>Sent:</b> Wednesday, January 05, 2022 6:44 AM<br>
<b>To:</b> llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [llvm-dev] Implicit Defs and Uses are ignored by pre-RA schedulers<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><b><i><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:red">EXTERNAL</span></i></b><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:red">
</span><o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Hello,<br>
<br>
In our Kalray LLVM backend, we have builtins to get and set system registers. One of them is $CS, which has sticky bits enforcing rounding mode or storing masked floating-point exceptions. The equivalent on AArch64 would be FPCR.<br>
<br>
In our user code, we would like to preserve the partial ordering between a SET to $CS and a floating-point operation, since the SET to $CS might be modifying the rounding mode. Similarly, we would like to preserve the partial ordering between a GET from $CS
and a floating-point operation, since a user code might want to examine the floating-point exception bits right after a given floating-point operation.<br>
<br>
Another use-case we have is the following: we have a coprocessor that is turned on by setting a given bit on a system register. This can be accessed by a builtin. Such SET instruction must happen before using a coprocessor instruction - the compiler should
not break that dependency when reordering instructions.<br>
<br>
We have tried to implement this by using implicit Defs and implicit Uses in our instruction definitions, using for example `Defs = [CS] in` and `Uses = [CS]` where relevant in our Target Description files.<br>
<br>
I have been running some experiments, examining the scheduling outputs and the dependencies (using VLIWScheduler in pre-RA, PostRASchedulerList in post-RA, and a child of VLIWPacketizerList for bundling).<br>
<br>
I have found that the implicit defs and uses are indeed taken into account by the post-RA schedulers. However, they seem to be ignored by the pre-RA schedulers. Also, they do not appear as dependencies in the SelectionDAG.<br>
<br>
If I look at what some other backends did, AArch64 does not seem to model anything on FPCR. PowerPC sets MFFS as scheduling barrier (isSchedulingBoundary) to prevent floating-point instructions being ordered above it - but isSchedulingBoundary seems to be only
used by post-RA schedulers; pre-RA schedulers do not seem to care about that.<br>
<br>
The bad consequence for us: our programmers have to encapsulate the SET instructions (touching system registers) in non-inlined functions to enforce the compiler not breaking anything.<br>
<br>
We are looking for advice on how to treat this problem - we have possible leads, like modifying the SelectionDAG to recover these dependencies, or modifying the schedulers to scan the SelectionDAG and enforce the source order when such dependency is detected
(maybe by having a look at how SourceScheduler works), but we have not yet investigated it fully.<br>
<br>
Any such advice would be greatly appreciated<br>
<br>
Also, another related issue: it would seem that the flag -ffp-exception-behavior=strict does not preserve the exception semantics like it says it does. Although the generated IR seems to preserve it, there does not seem to be anything in the LLVM backends enforcing
the "strict" floating-point exception behavior.<br>
<br>
That last point can be witnessed in that piece of code: <a href="https://godbolt.org/z/e96zP7jET">
https://godbolt.org/z/e96zP7jET</a><br>
<br>
```<br>
long fpcr;<br>
<br>
int toto(float a, float b, float c, double d, double e){<br>
float bc = b + c; // first faddd<br>
asm("mrs %[result], FPCR" : [result] "=r" (fpcr) : :);<br>
float abc = a + bc; // second faddd<br>
float dw = (float) d; // fwidenlwd : should not happen before the second faddd<br>
float ew = (float) e;<br>
int dw_ewl = (int) dw + (int) ew;<br>
int abcl_dw_ewl = (int) abc + dw_ewl;<br>
return abcl_dw_ewl;<br>
}<br>
<br>
```<br>
<br>
Compiling this piece of code with clang 11.0.0 for ARMv8-a gives the following assembly code:<br>
```<br>
toto:<br>
fadd s1, s1, s2<br>
fcvt s2, d3<br>
fadd s0, s1, s0<br>
fcvt s3, d4<br>
fcvtzs w9, s2<br>
fcvtzs w10, s0<br>
add w9, w10, w9<br>
fcvtzs w10, s3<br>
add w0, w9, w10<br>
adrp x9, fpcr<br>
//APP<br>
mrs x8, FPCR<br>
//NO_APP<br>
str x8, [x9, :lo12:fpcr]<br>
ret<br>
```<br>
<br>
Notice that mrs was moved below - which does not seem to preserve the floating-point exception semantics of the compiled code.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">PS : apologies for the double message if any ; I sent the first to llvm-dev-bounces by mistake<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Best regards,<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><strong><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#144444">Cyril Six</span></strong><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><br>
</span><strong><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#144444">Compiler Engineer • Kalray</span></strong><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><br>
</span><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#144444">Phone:
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><br>
</span><u><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#11588F"><a href="mailto:csix@kalrayinc.com">csix@kalrayinc.com</a></span></u><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#11588F"> •
<a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kalrayinc.com%2F&data=04%7C01%7Ckevin.neal%40sas.com%7Cf6449a7fc514491496e808d9d040c161%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C637769798860724868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2JlQXniNWcZMWA1G%2BX2LMsw6crfX4kCh0UGCDDAmx2w%3D&reserved=0" target="_blank">
<span style="color:#11588F">www.kalrayinc.com</span></a></span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">
<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<table class="MsoNormalTable" border="0" cellpadding="0">
<tbody>
<tr>
<td style="padding:.75pt .75pt .75pt .75pt">
<div>
<p class="MsoNormal"><a href="https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kalrayinc.com%2F&data=04%7C01%7Ckevin.neal%40sas.com%7Cf6449a7fc514491496e808d9d040c161%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C637769798860724868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=2JlQXniNWcZMWA1G%2BX2LMsw6crfX4kCh0UGCDDAmx2w%3D&reserved=0" target="_blank"><span style="text-decoration:none"><img border="0" width="294" height="47" style="width:3.0625in;height:.4895in" id="_x0000_i1025" src="http://data.kalrayinc.com/Kalray_72.png" alt="Kalray logo"></span></a><o:p></o:p></p>
</div>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><br>
</span><strong><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#7DB621">Please consider the environment before printing this e-mail.</span></strong><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#144444">This message contains information that may be privileged or confidential and is the property of Kalray S.A. It is intended only for the person to whom it is addressed.
If you are not the intended recipient, you are not authorized to print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this
message.</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>