<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 02/14/2017 12:25 PM, Kaylor, Andrew
wrote:<br>
</div>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE576C9DB0@ORSMSX115.amr.corp.intel.com"
type="cite">
<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;}
/* 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.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle21
{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]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Hi Hal,<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">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></p>
</div>
</blockquote>
<br>
SGTM.<br>
<br>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE576C9DB0@ORSMSX115.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D"><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 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:
<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"> bool
HasPhysRegOuts = NumResults > NumDefs &&
II.getImplicitDefs()!=nullptr;<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">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></p>
</div>
</blockquote>
<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>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE576C9DB0@ORSMSX115.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D"><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’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></p>
</div>
</blockquote>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE576C9DB0@ORSMSX115.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D"><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">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></p>
</div>
</blockquote>
<br>
Makes sense to me.<br>
<br>
<blockquote
cite="mid:0983E6C011D2DC4188F8761B533492DE576C9DB0@ORSMSX115.amr.corp.intel.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D"><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">Thanks,<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>
<p class="MsoNormal"><a moz-do-not-send="true"
name="_MailEndCompose"><span style="color:#1F497D"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><a moz-do-not-send="true"
name="_____replyseparator"></a><b><span
style="color:windowtext">From:</span></b><span
style="color:windowtext"> Hal Finkel
[<a class="moz-txt-link-freetext" 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 class="moz-txt-link-rfc2396E" 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<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/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"><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>
<o:p></o:p></span></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"><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>
<o:p></o:p></span></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"><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>
<o:p></o:p></span></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"><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>
<o:p></o:p></span></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"><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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>