<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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \,serif";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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 bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> We should probably also enumerate what we're trying to do here. For example, I can't<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> CSE (or hoist, etc.) a FP-operation across a call boundary that might change the<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> rounding mode (if the call might change the rounding mode and the FP instructions<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> read it) or if the call might query the FP environment (and the FP operations are<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">> tagged as writing it).</span><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><span style="color:#1F497D">This is a very good point!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Having added implicit defs to the instructions that read and write the SEE FP control register (MXCSR), if I also add the implicit uses of that register by the FP operations (as you said PowerPC already has),
then I won’t need to do anything to prevent code motion across function calls or instructions that change the rounding mode.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">However, I also need to prevent code motion of FP operations relative to instructions that read the FP exception status. I could accomplish this by modeling the fact that FP operations def the FP exception status,
but I don’t want to inhibit code motion of FP operations relative to one another (at least not in the non-constrained case, and it’s probably not even necessary in the constrained case). I think if I model the FP instructions as having a def but not a use
of the status register that would do what I need it to.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I believe we agreed at the dev meeting that we don’t intend to guarantee the order in which FP operations are executed relative to when FP exceptions occur.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The SSE and later instructions introduce a slight wrinkle in that the same register is used (implicitly) for control and status, but I don’t see a reason why we couldn’t model it as two different registers since
it isn’t referenced directly anyway. Technically the FP instructions do read the exception status bits, but I think we can ignore that since they never clear bits, only set them.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">So maybe I don’t need the constrained FP handling to do anything at all if the default handling can do all of the following without loss of performance:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Model defs for instructions that write the FP control bits<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Model uses of the FP control bits for all FP operations<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Model defs of the FP status bits for all FP operations<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Model uses of the FP status bits for instructions that read them<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Does that sound correct?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I think that only concern that would leave for constrained FP handling is that we need to make sure that no FP instructions are speculatively executed, but I don’t think the implicit def/use modeling would help
with that anyway. I’ve been operating on the assumption that it just doesn’t happen right now (which appears to be true), but I’m not sure there is anything that prevents it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><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"><a name="_____replyseparator"></a><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> Hal Finkel [mailto:hfinkel@anl.gov]
<br>
<b>Sent:</b> Tuesday, February 14, 2017 11:22 AM<br>
<b>To:</b> Kaylor, Andrew <andrew.kaylor@intel.com>; llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: Adding FP environment register modeling for constrained FP nodes<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal">On 02/14/2017 12:25 PM, Kaylor, Andrew wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="color:#1F497D">Hi Hal,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks for the guidance. I hope you don’t mind that I’m adding LLVMDev to this e-mail thread, as it seems as though it may be of general interest.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><br>
SGTM.<br>
<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">I agree that duplicating the FP opcodes should be our goal. I just wasn’t sure that was entirely possible. I’ll try adding implicit defs in the way you’ve suggested, but I’m concerned that there may be code
that relies on the TII for that kind of thing -- for instance, InstrEmitter::EmitMachineNode() does this:
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> bool HasPhysRegOuts = NumResults > NumDefs && II.getImplicitDefs()!=nullptr;</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">where “NumDefs” comes from TII and “NumResults” comes from the node. Obviously we can fix that up as needed, but it seems like a weak point in the design. Perhaps it is still better than trying to maintain
a duplicate set of opcodes though.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><br>
Good point. I think it is better to update (fix) code that does not handle dynamically-added implicit operands than trying to handle duplicated opcodes all over the place. FWIW, having code with InstrEmitter with this kind of assumption does not surprise me
particularly (at that point in the pipeline, nothing else would have added any dynamic implicit defs yet).<br>
<br>
I'm also happy to think about other ways to do this. We could have the instructions, by default, carry full dependencies and then relax them as desired (instead of the other way around).<br>
<br>
We should probably also enumerate what we're trying to do here. For example, I can't CSE (or hoist, etc.) a FP-operation across a call boundary that might change the rounding mode (if the call might change the rounding mode and the FP instructions read it)
or if the call might query the FP environment (and the FP operations are tagged as writing it).<br>
<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">I’m still trying to piece together how to get the set of nodes to be updated from the SelectionDAG to the InstrEmitter. I’m still learning my way around this code.</span><o:p></o:p></p>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">In any event, I can confirm that for X86 targets the control register uses are not currently modeled. I just committed a patch yesterday adding the MXCSR register and updating the instructions that directly
read and write it (but still implicitly so). I suppose you are correct that there is no reason not to add uses of that register to the instructions that derive their rounding behavior from it and then the constrained FP intrinsics will just need to add implicit
defs where needed. I’ll also need to add the x87 control register as that isn’t modeled at all right now.</span><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><br>
Makes sense to me.<br>
<br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Andy</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><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><span style="color:windowtext">From:</span></b><span style="color:windowtext"> Hal Finkel [<a href="mailto:hfinkel@anl.gov">mailto:hfinkel@anl.gov</a>]
<br>
<b>Sent:</b> Friday, February 10, 2017 4:58 PM<br>
<b>To:</b> Kaylor, Andrew <a href="mailto:andrew.kaylor@intel.com"><andrew.kaylor@intel.com></a><br>
<b>Subject:</b> Re: Adding FP environment register modeling for constrained FP nodes</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal">On 02/09/2017 06:41 PM, Kaylor, Andrew wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi Hal,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I’ve been trying to figure out enough of the instruction selection code to be able to attach implicit use/def information for DAG nodes that have been selected from constrained FP pseudo-ops. You seemed to have a clear idea in your mind
of how this could be done. I had an idea for what I intended, but I didn’t really know how to do it.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">As I’ve been digging in to this, it seems that my idea that the implicit register use was something I could just append to an existing node was incorrect. If I understand correctly, the implicit register use often (if not always) comes
from TargetInstrInfo queries based on the opcode. If this is right, then I’d need to introduce a new machine opcode for any instruction that I wanted to have an implicit register use. For instance, if we just mutated ISD::STRICT_FADD to ISD::FADD and Select
changed that to X86::MULSDrm, then to attach implicit MXCSR use to that I’d need a new opcode (X86::MULSDrm_Strict) that behaves just like X86::MULSDrm but has the implicit MXCSR use/def information associated with it.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Does it sound like I’m understanding this correctly? <o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman ,serif",serif"><br>
You're correct that implicit operands normally come from the instruction definitions, but you can add whatever other implicit operands you'd like. We often do this to handle calls, returns, etc. - we add implicit operands corresponding to parameters and return
values.<br>
<br>
My thought was that, in SelectionDAGISel::DoInstructionSelection, after the call to Select, Node should have been mutated to be the associated machine instruction. We can then have a target hook which then updates the node operands to also have the implicit
register dependencies. However, that does not explain how to actually do that: At the MI level, you can always call addOperand to add another implicit operand. Adding implicit uses at the SDAG level is also straightforward (because you can mutate the node
to have additional operands that you get by calling CurDAG->getRegister(...).<br>
<br>
I think the easiest way to do this is to add a map of the nodes to which we need to add the extra operands, and then we can just add the additional operands at the MI level from InstrEmitter.cpp after we otherwise build the MI representation for the instruction.<br>
<br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">If so, is there a simple way to create these duplicate opcodes? I’m looking at .td files trying to figure it out and it’s looking like a can of worms. Is there a way to do this from TableGen’s
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman ,serif",serif"><br>
I specifically want to do this without duplicating the opcodes if possible. Duplicating the opcodes requires a lot more code changes to the backends that I'd like to avoid.<br>
<br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">CodeGenDAGPatterns::GenerateVariants()?<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I’m also not sure I know what I’m doing with finding the nodes that need to be updated. In the simplest case the FP node gets updated directly into a single machine opcode node, but I don’t think that always happens and I’m not sure I
can even count on the original node not being deleted. I’ve experimented with using a DAGUpdateListener, but I’m not sure that does everything I need it to. Am I overthinking this?<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman ,serif",serif"><br>
I think you're on the right track. DAGUpdateListener seems like the right approach. ISel already uses these for other purposes, and this will allow to do track what has happened to the node being instruction-selected. You're correct that there might be more
than one instruction created as a result, but I don't think that should be a problem because you should only need to modify the final instruction.<br>
<br>
At least on PowerPC, all of the floating-point instructions are already given implicit (use) operands of RM (which stands for 'rounding mode', but is used to represent all of the FP-environment state). None of these instructions, however, define RM, so there
are no dependencies created. I think that the target callback on PowerPC would just need to add an implicit register def of 'RM' to the "final" instruction representing any operation to create the necessary dependency relationships.<br>
<br>
X86 might not have these implicit uses already?<br>
<br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I’m starting to wonder if it might be better to back out what I did in the ISel and just require target-specific pattern matching and whatever other implementation bits are needed.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">On the good news side of things, I wrote a simple function pass to translate all FP operations into the constrained intrinsics and with that pass being run as early as possible I can successfully run some real-world programs with extensive
FP usage.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman ,serif",serif"><br>
Neat :-)<br>
<br>
I imagined that the way we'd do this is by putting a mode into the IRBuilder where it will generate the intrinsics instead of the regular instructions (kind of like it has a mode in which it will add fast-math flags by default).<br>
<br>
Thanks again,<br>
Hal<br>
<br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Anyway, if you can offer any guidance and tell me whether or not I’m heading in the right direction I would be very grateful.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Andy<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman ,serif",serif"><br>
<br>
<br>
</span><o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>Hal Finkel<o:p></o:p></pre>
<pre>Lead, Compiler Technology and Programming Languages<o:p></o:p></pre>
<pre>Leadership Computing Facility<o:p></o:p></pre>
<pre>Argonne National Laboratory<o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><br>
<br>
<o:p></o:p></span></p>
<pre>-- <o:p></o:p></pre>
<pre>Hal Finkel<o:p></o:p></pre>
<pre>Lead, Compiler Technology and Programming Languages<o:p></o:p></pre>
<pre>Leadership Computing Facility<o:p></o:p></pre>
<pre>Argonne National Laboratory<o:p></o:p></pre>
</div>
</body>
</html>