<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div id="content_out_csix_kalrayinc.com"></div><div class="moz-cite-prefix">Thanks a lot for the replies,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 1/5/22 3:44 PM, Wang, Phoebe wrote:<br>
</div>
<blockquote type="cite" cite="mid:PH0PR11MB5627E35D6287E04B0E0D2B08EB4B9@PH0PR11MB5627.namprd11.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}@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;}@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}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.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;
font-weight:normal;
font-style:normal;
text-decoration:none none;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}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"><span style="color:#1F497D">Did you try
`hasSideEffects = 1`?</span></p>
<p class="MsoNormal"><span style="color:#1F497D">I’m not
familiar with AArch64. On X86, we have separate FPCR and
FPSR. The former is used for control (rounding, exception
mask) and the latter is for status. We modeled all FP
instructions that may raise exception by
`mayRaiseFPException = 1` and using FPCR. Note, the read of
FPCR instruction is another use instead of def FPCR. So it’s
not necessary to keep the order of read instruction ahead as
source order. Only the write FPCR does. I guess it is the
same reason for AArch64? Maybe you can have a check on the
write of FPCR.</span></p>
<p class="MsoNormal"><span style="color:#1F497D"><p> </p></span></p>
<div>
<p class="MsoNormal"><span style="color:#1F497D">Thanks</span></p>
<p class="MsoNormal"><span style="color:#1F497D">Phoebe</span></p>
</div>
</div>
</blockquote>
<p>On our end, hasSideEffects = 1 and mayRaiseFPException = 1
(combined with implicit Defs and Uses of our $CS register) do not
seem to be enough to prevent the reordering of floating-point
instructions in pre-RA scheduling.</p>
<p>On 1/6/22 9:32 PM, Kevin Neal wrote:<br>
</p><blockquote type="cite">
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'>Correct. You do need to add the
required support to your backend.</span></p>
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'> </span></p>
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'>The X86, PowerPC, and SystemZ
backends have basically complete support.</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</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</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</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</span></p>
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'>examine and emulate.</span></p>
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'> </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</span></p>
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'>progress, so be prepared for
not-so-great performance.</span></p>
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'> </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</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</span></p>
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'>has been implemented.</span></p>
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'> </span></p>
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'> </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</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</span></p>
<p class="MsoNormal"><span style='font-family:"Courier
New";color:#44546A'>disabled. I don't remember exactly
which release first had this.</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</span></p>
<p class="MsoNormal"><span style='font-size:10.0pt;font-family:"Courier
New";color:#44546A'>Compute Services</span></p>
<span style='font-size:10.0pt;font-family:"Courier
New";color:#44546A'>SAS Institute, Inc.</span></blockquote>
<p>Thank you for the answer - it confirms what I have been seeing.</p>
<p>I will take a closer look to these backends, especially PowerPC's
fix to not reschedule floating-point instructions above function
calls.<br>
</p>
<p>Cyril S<br>
</p>
<blockquote type="cite" cite="mid:PH0PR11MB5627E35D6287E04B0E0D2B08EB4B9@PH0PR11MB5627.namprd11.prod.outlook.com">
<div class="WordSection1">
<div>
</div>
<p class="MsoNormal"><span style="color:#1F497D"><p> </p></span></p>
<div>
<p id="fb_identificator"></p>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev
<a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev-bounces@lists.llvm.org"><llvm-dev-bounces@lists.llvm.org></a> <b>On Behalf Of
</b>Cyril Six via llvm-dev<br>
<b>Sent:</b> Wednesday, January 5, 2022 7:44 PM<br>
<b>To:</b> llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><llvm-dev@lists.llvm.org></a><br>
<b>Subject:</b> [llvm-dev] Implicit Defs and Uses are
ignored by pre-RA schedulers</p>
</div>
</div>
<p class="MsoNormal"><p> </p></p>
<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" moz-do-not-send="true">
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.</span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:black'><p> </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</span></p>
</div>
<div>
<p class="MsoNormal"><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:black'><p> </p></span></p>
<div>
<p class="MsoNormal"><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:black'>Best
regards,</span></p>
</div>
<p class="MsoNormal"><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:black'><p> </p></span></p>
<div>
<p class="MsoNormal"><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:black'><p> </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" moz-do-not-send="true">csix@kalrayinc.com</a></span></u><span style='font-size:8.0pt;font-family:"Arial",sans-serif;color:#11588F'>
•
<a href="https://www.kalrayinc.com" target="_blank" moz-do-not-send="true"><span style="color:#11588F">www.kalrayinc.com</span></a></span><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:black'>
</span></p>
</div>
<p class="MsoNormal"><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:black'><p> </p></span></p>
<table class="MsoNormalTable" cellspacing="4" cellpadding="0" border="0">
<tbody>
<tr>
<td style="padding:.75pt .75pt .75pt .75pt">
<div>
<p class="MsoNormal"><a href="https://www.kalrayinc.com/" target="_blank" moz-do-not-send="true"><span style="text-decoration:none"><img style="width:3.0625in;height:.4895in" id="_x0000_i1025" src="http://data.kalrayinc.com/Kalray_72.png" alt="Kalray logo" moz-do-not-send="true" width="294" height="47" border="0"></span></a></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'></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'></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span style='font-size:12.0pt;font-family:"Arial",sans-serif;color:black'><p> </p></span></p>
</div>
</div>
</div>
</blockquote>
</body>
</html>