<html 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:Helvetica;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@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:Menlo;
panose-1:2 11 6 9 3 8 4 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
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;}
span.gmail-m-4093945600506763570apple-converted-space
{mso-style-name:gmail-m_-4093945600506763570apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
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>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">This is interesting. This seems to solve most of my main issue, although it’s still a bit strange to carry around a builder when doing something a little more complex than directly forwarding to the next call. I’ll try using this for a
while and see how much nicer it is. Thanks!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Matt<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Aditya Nandakumar <proaditya@gmail.com><br>
<b>Date: </b>Wednesday, January 30, 2019 at 10:21 PM<br>
<b>To: </b>Amara Emerson <aemerson@apple.com><br>
<b>Cc: </b>"Arsenault, Matthew" <Matthew.Arsenault@amd.com>, llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Subject: </b>Re: [llvm-dev] MachineIRBuilder API<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is already possible. <o:p></o:p></p>
<div>
<p class="MsoNormal">To do the equivalent of what you mentioned, this should do it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">auto Add = Builder.buildAdd(LLT::scalar(32), Src1, Src);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">auto Mul = Builder.buildMul(LLT::scalar(32), Add, Src3);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Jan 30, 2019 at 6:57 PM Amara Emerson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">I agree that it’s annoying to have to create VRegs manually. I haven’t thought this through deeply but perhaps having a utility wrapper class to capture the destination regs of a newly built instruction could help, e.g. something like:
<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-family:Menlo">InstReg AddReg(MIRBuilder.buildAdd(LLT::scalar(32), Src1, Src));</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Menlo">InstReg MulReg(MIRBuilder.buildMul(LLT::scalar(32), AddReg.get(), Src3));</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Menlo">// etc etc</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Where InstReg could be something like:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Menlo">class InstReg {</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Menlo"> unsigned Reg = 0;</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Menlo">public:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Menlo"> InstReg(MachineInstrBuilder &MIB) : Reg(MIB.getInstr().getOperand(0).getReg()) {}</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Menlo"> unsigned getReg() { return Reg; }</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:Menlo">};</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This example only works for single dest reg instructions but could be extended for any number of regs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Amara<o:p></o:p></p>
</div>
<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 30 Jan 2019, at 18:43, Arsenault, Matthew via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">I’m less interested in literally passing the output of one as an argument to the next such that argument evaluation order matters. Intermediate register variables are fine. It would still be less code to have tmp
= buildFoo(), buildFoo(tmp) than the current code required to manage the register<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:white">-Matt<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:white">From:<span class="gmail-m-4093945600506763570apple-converted-space"> </span></span></b><span style="font-size:12.0pt;color:white"><<a href="mailto:daniel_l_sanders@apple.com" target="_blank">daniel_l_sanders@apple.com</a>>
on behalf of Daniel Sanders <<a href="mailto:daniel_l_sanders@apple.com" target="_blank">daniel_l_sanders@apple.com</a>><br>
<b>Date:<span class="gmail-m-4093945600506763570apple-converted-space"> </span></b>Wednesday, January 30, 2019 at 9:32 PM<br>
<b>To:<span class="gmail-m-4093945600506763570apple-converted-space"> </span></b>"Arsenault, Matthew" <<a href="mailto:Matthew.Arsenault@amd.com" target="_blank">Matthew.Arsenault@amd.com</a>><br>
<b>Cc:<span class="gmail-m-4093945600506763570apple-converted-space"> </span></b>llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:<span class="gmail-m-4093945600506763570apple-converted-space"> </span></b>Re: [llvm-dev] MachineIRBuilder API</span><span style="color:white"><o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:white">Hi Matt,<span class="gmail-m-4093945600506763570apple-converted-space"> </span><o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">Personally, I like that it follows the same pattern as MachineInstrBuilder used elsewhere in MIR. It would certainly be nice to create whole expressions at once though.<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">I believe that nested SelectionDAG-style get*() functions have an ordering problem when used for MIR that wasn't a problem for SelectionDAG due to the difference in underlying representation. The DAG didn't really
care which evaluation order happened as the de-duplication and unordered nature of the DAG produced the same result either way. For MIR, each builder needs to insert into a linear list so the evaluation order of those insertions matters. For example:<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">getAdd(getSub(a, b), getMul(c, d))<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">could produce either:<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">%0 = G_SUB %a, %b<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">%1 = G_MUL %c, %d<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">%2 = G_ADD %0, %1<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">or:<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">%0 = G_MUL %c, %d<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">%1 = G_SUB %a, %b<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">%2 = G_ADD %1, %0<o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">depending on the (indeterminate) evaluation order of the arguments to getAdd(). The G_ADD is always last because getSub() and getMul() must execute before getAdd() but AFAIK there's nothing that controls the relative
order that getSub() and getMul() are evaluated and inserted beyond saying that they aren't interleaved. If I'm interpreting<span class="gmail-m-4093945600506763570apple-converted-space"> </span><a href="https://en.cppreference.com/w/cpp/language/eval_order" target="_blank"><span style="color:purple">https://en.cppreference.com/w/cpp/language/eval_order</span></a> correctly,
C++17 makes it more explicit than the old rules (rule 15 in particular).<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:white"><o:p> </o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="color:white">On Jan 30, 2019, at 16:55, Arsenault, Matthew via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><span style="color:purple">llvm-dev@lists.llvm.org</span></a>> wrote:<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">Hi,<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">I’m finding the API for MachineIRBuilder to be pretty annoying to use compared to SelectionDAG. I think it’s making the majority of code more verbose and unwieldly for anything less than trivial. I think changing
it to behave more like the DAG.get* functions would make it easier to use, and decrease the mental overhead when porting code from SelectionDAG.<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">The main issue is needing to create and/or manage the registers used separately from the instruction creation. Normally you have to create a generic virtual register with the correct output type. When a lot of
intermediate values are needed, this can get pretty messy. There is an alternative provided, but I don’t think it’s really any better. You can construct a DstOp from an LLT, which will create a new register. You would then need to use the returned instruction,
get the destination register from the output and use that. This doesn’t allow you to naturally compose operations by using the return value of a build* function to another. I also find this aspect to be pretty error prone, as I discovered it by accident when
the registers I had already created weren’t being used.<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">The current set of build* functions all return MachineInstrBuilder, or effectively the inserted instruction. This seems reasonable for some odd low level cases where you are building an instruction that won’t be
inserted yet, or you don’t know the operands ahead of time. For the majority of code, I don’t see how this is useful. Most places should be using a buildFooInstr type of instruction, which creates and inserts a specific opcode (or set of similar behaving opcodes)
with all of the necessary operands. The instruction is already inserted, and can’t have additional operands added, so there isn’t really anything to do with it.<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">It would be more helpful if these were returning the register / logical value, similar to what you get with DAG.getNode(). In the odd case you actually want the instruction, you could check the instruction before
the insert point.<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">Does anyone feel strongly that these functions should be returning the builder? What I would like to do is either replace and complete the current set of buildOpcode functions with ones which return the output
register value, or add an alternative set which do. Is it worth having two sets of functions (a buildFoo and getFoo set?). The same issue applies with opcodes producing multiple results, such as buildUnmerge, but in that case I would probably change these
to a SmallVectorImpl out argument.<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">Another minor issue I’ve run into is when trying to add convenience functions with constants (e.g. shift creation with materializing the amount constant). With an overload using a SrcOp constructible from “unsigned”,
and one using an integer type, the wrong one gets called and ends up creating a constant with the value of the register. I think this is more a symptom of using a plain unsigned for registers, but fixing this longstanding mistake everywhere would be a very
large project.<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:white">-Matt<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Helvetica;color:white">_______________________________________________<br>
LLVM Developers mailing list<br>
</span><span style="color:white"><a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><span style="font-size:9.0pt;font-family:Helvetica;color:#954F72">llvm-dev@lists.llvm.org</span></a></span><span style="font-size:9.0pt;font-family:Helvetica;color:white"><br>
</span><span style="color:white"><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank"><span style="font-size:9.0pt;font-family:Helvetica;color:#954F72">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</span></a><o:p></o:p></span></p>
</div>
</div>
</blockquote>
</div>
<div>
<p class="MsoNormal"><span style="color:white"> <o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:Helvetica;color:white">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span><o:p></o:p></p>
</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" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Regards,<br>
Aditya<o:p></o:p></p>
</div>
</div>
</body>
</html>