<div dir="ltr">Just seeing this, nothing to add to what James said. FWIW I agree the name is somewhat misleading, we use it rather like s/shouldIgnoreForPipelining/shouldFailWhenPipelined/, nor is it called by anything upstream, so maybe the API is somewhat unnecessary IMO.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 1:23 AM Nagurne, James <<a href="mailto:j-nagurne@ti.com">j-nagurne@ti.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
The target is downstream.<br>
<br>
JB
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-7755934519888762400divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> James Molloy <<a href="mailto:jmolloy@google.com" target="_blank">jmolloy@google.com</a>><br>
<b>Sent:</b> Wednesday, September 9, 2020 2:08:04 AM<br>
<b>To:</b> Nagurne, James<br>
<b>Cc:</b> Jinsong Ji; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Sander; Hendrik Greving<br>
<b>Subject:</b> Re: [EXTERNAL] RE: [llvm-dev] Machinepipeliner interface. shouldIgnoreForPipelining, actually not ignoring.</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi James,
<div><br>
</div>
<div>One last thing - is your target upstream? or are you working on a downstream target?</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>James</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 8 Sep 2020 at 23:02, Nagurne, James <<a href="mailto:j-nagurne@ti.com" target="_blank">j-nagurne@ti.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I greatly appreciate you going back to gather that intel, James. It actually helps my understanding of the whole pipeliner puzzle quite a bit!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I did identify, like you, that the MachinePipeliner pass (more precisely, SwingSchedulerDAG) was fairly rigid in that the target doesn’t get much of a say
in some heuristics or in the generation of the result loop. I’m definitely still in a learning phase and am poking around to see where<a name="m_-7755934519888762400_m_-7858431833642170456__MailEndCompose"> we can customize some things. It might very well come down to the same decision
to write our own pass that implements our own scheduler, and then utilize ModuloSchedule and an Expander to make changes. One interesting topic that came up was unrolling to get more utilization of the FUs. Someone had already identified this optimization
in </a><a href="https://reviews.llvm.org/D53005" target="_blank">https://reviews.llvm.org/D53005</a>, but it seems to have gone stale. I’m also curious about customizing the expander, since we too have some ways to make the prolog and epilog more efficient.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">My current solution hides the PHI and IndVar update instructions added by HardwareLoops inside the branch and rematerializes them after the stock MachinePipeliner
runs. Not having to do that would be great, but now that it’s implemented, I think I can stop bothering you guys for historical data!
</span><span style="font-size:11pt;font-family:Wingdings;color:rgb(31,73,125)">J</span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Thanks again!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">JB<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> James Molloy [mailto:<a href="mailto:jmolloy@google.com" target="_blank">jmolloy@google.com</a>]
<br>
<b>Sent:</b> Monday, September 7, 2020 1:49 AM<br>
<b>To:</b> Nagurne, James<br>
<b>Cc:</b> Jinsong Ji; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Sander; Hendrik Greving<br>
<b>Subject:</b> Re: [EXTERNAL] RE: [llvm-dev] Machinepipeliner interface. shouldIgnoreForPipelining, actually not ignoring.<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Hi James,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Having not worked on this for circa one year I've gone and refreshed my memory.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We have a pretty capable implementation of swing modulo scheduling downstream, distinct from the MachinePipeliner implementation. Historically, MachinePipeliner had very tight coupling between the finding of a suitable schedule and emitting
the code that adheres to that schedule.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I spent quite a bit of time separating the two; this led to the "ModuloSchedule" and "ModuloScheduleExpander" classes, which we use downstream too (we actually have a minor variant, where we use predication for the prolog and epilog). However,
the code that analyzes loops and determines a good schedule is completely custom. It is in this code that we use "shouldIgnoreForPipelining".<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">All of this code is designed to go upstream. There is nothing stopping us putting it upstream (modulo some non-upstreamable features that may have crept in, but those can be removed). The major hurdle is that the target architecture is
NOT upstream, and no existing upstream architecture looks similar enough apart from Hexagon (RISC, VLIW, predicate register file), and we don't have enough knowledge of Hexagon to use it as a testing target.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We toyed with the idea of coming up with a toy architecture just so we could have something to test against upstream, but the personpower required wasn't available.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As always, it was with the best of intentions, and I do think that the cleanup of MachinePipeliner was worth it (the PeelingScheduleExpander is much easier to reason about, IMHO).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Cheers,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">James<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, 3 Sep 2020 at 20:41, Nagurne, James <<a href="mailto:j-nagurne@ti.com" target="_blank">j-nagurne@ti.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">We have that behaves similarly to yours in this regard it seems. Specifically, our target utilizes the HardwareLoop pass with CounterInReg true, and then treats
loops augmented by this pass as software pipeline candidates. It seems PPC does this as well, but has CounterInReg false. Our loop body ends up looking like this (in mildly simplified pseudocode):</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">%body:</span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> %indvar = PHI(%init, %preheader, %dec, %body)</span></b><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> …</span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> %dec = subtract %indvar, count</span></b><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> branch-compare (%dec > 0), %body</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> branch %end</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">%end:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> …</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">The instructions I’ve bolded cause problems in the pipeliner as you are well aware. They are the induction variable updates that shouldn’t be pipelined and
will be re-inserted or updated post-scheduling. When I saw “ignoreForPipelining” I was excited that the problem was already solved, but alas!
</span><span style="font-size:11pt;font-family:Wingdings;color:rgb(31,73,125)">J</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I’m in the process of trying to come up with a workaround pass before/after pipelining that temporarily hides these instructions inside the branch, but I’m
always on the lookout for better alternatives.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Thanks for the response! I would appreciate anything that Hendrik could add to the discussion as well. If it’s just that the implementation isn’t robust enough
to upstream, our team might be amenable to help out. I do, however, wonder if the implementation was used in a custom scheduler rather than the default SMS and expander. That would make generalizing quite a bit tougher.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">JB</span><u></u><u></u></p>
<p class="MsoNormal"><a name="m_-7755934519888762400_m_-7858431833642170456_m_3100822039920227032__MailEndCompose"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></a><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> James Molloy [mailto:<a href="mailto:jmolloy@google.com" target="_blank">jmolloy@google.com</a>]
<br>
<b>Sent:</b> Thursday, September 3, 2020 2:07 PM<br>
<b>To:</b> Nagurne, James<br>
<b>Cc:</b> Jinsong Ji; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Sander; Hendrik Greving<br>
<b>Subject:</b> Re: [EXTERNAL] RE: [llvm-dev] Machinepipeliner interface. shouldIgnoreForPipelining, actually not ignoring.</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Hi James,<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Adding Hendrik, who has taken over ownership of the downstream code involved. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I can also add background about the rationale, of that helps? It was added to ignore induction variable update code (scalar code) that is rewritten when we unroll / peel the prolog epilog anyway. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Targets like Hexagon or PPC with dedicated loop control instructions for pipelined loops don't need this, but our target was simple RISC. It was for that reason that I felt the feature would be useful for other targets. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">James<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, 3 Sep 2020, 17:19 Nagurne, James, <<a href="mailto:j-nagurne@ti.com" target="_blank">j-nagurne@ti.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Ah, I apologize for not seeing the meaning of your first email. I had not considered that he was working on an out-of-tree target that utilizes the ignore
capability. You’ve made things very clear, thank you!</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Since he’s on the email thread now:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">James, do you plan on upstreaming any portion of the ignore capability? If not, do you have any pointers for a target that may want to implement it? The one
issue I see that might exist is that the scheduler wants a region begin and end as iterators, meaning contiguous instructions. It doesn’t really support the removal of instructions between those two points, so you’d have to synthesize a region, create a meta-iterator,
or some other intrusive modification.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">JB</span><u></u><u></u></p>
<p class="MsoNormal"><a name="m_-7755934519888762400_m_-7858431833642170456_m_3100822039920227032_m_-236644962968211"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></a><u></u><u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Jinsong Ji [mailto:<a href="mailto:jji@us.ibm.com" target="_blank">jji@us.ibm.com</a>]
<br>
<b>Sent:</b> Thursday, September 3, 2020 10:03 AM<br>
<b>To:</b> Nagurne, James; <a href="mailto:jmolloy@google.com" target="_blank">jmolloy@google.com</a><br>
<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Sander<br>
<b>Subject:</b> [EXTERNAL] RE: [llvm-dev] Machinepipeliner interface. shouldIgnoreForPipelining, actually not ignoring.</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p><span style="font-size:10pt">As I mentioned before, </span><br>
<span style="font-size:10pt">this API was introduced by James, mostly for his out-of-tree implementations,
</span><br>
<span style="font-size:10pt">the in tree implementation NEVER implement it.</span><br>
<br>
<span style="font-size:10pt">If it is causing confusion, I think we have two choices:</span><br>
<span style="font-size:10pt">1. See whether James would like to upstream part of his code? Or any other target that would like to use this can post a patch to use it.</span><br>
<span style="font-size:10pt">2. Remove this confusing API in tree.</span><br>
<br>
<span style="font-size:10pt"><br>
Best,<br>
<br>
Jinsong Ji (</span><span lang="ZH-CN" style="font-size:10pt;font-family:SimSun">纪金松</span><span style="font-size:10pt">), PhD.<br>
<br>
XL/LLVM on Power Compiler Development <br>
E-mail: <a href="mailto:jji@us.ibm.com" target="_blank">jji@us.ibm.com</a></span><br>
<br>
<b>Error! Filename not specified.</b><span style="font-size:10pt;color:rgb(66,66,130)">"Nagurne, James" ---09/02/2020 01:43:29 PM---Sorry to bring this thread from 3 months ago back, but I’m running into this issue too. I do see tha</span><br>
<br>
<span style="font-size:10pt;color:rgb(95,95,95)">From: </span><span style="font-size:10pt">"Nagurne, James" <<a href="mailto:j-nagurne@ti.com" target="_blank">j-nagurne@ti.com</a>></span><br>
<span style="font-size:10pt;color:rgb(95,95,95)">To: </span><span style="font-size:10pt">Jinsong Ji <<a href="mailto:jji@us.ibm.com" target="_blank">jji@us.ibm.com</a>>, Sander <<a href="mailto:sanderruben@gmail.com" target="_blank">sanderruben@gmail.com</a>></span><br>
<span style="font-size:10pt;color:rgb(95,95,95)">Cc: </span><span style="font-size:10pt">"<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span><br>
<span style="font-size:10pt;color:rgb(95,95,95)">Date: </span><span style="font-size:10pt">09/02/2020 01:43 PM</span><br>
<span style="font-size:10pt;color:rgb(95,95,95)">Subject: </span><span style="font-size:10pt">RE: [EXTERNAL] Re: [llvm-dev] Machinepipeliner interface. shouldIgnoreForPipelining, actually not ignoring.</span><u></u><u></u></p>
<div>
<div>
<div class="MsoNormal">
<hr size="2" width="100%" noshade style="color:rgb(128,145,165)" align="left">
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<span style="color:rgb(31,73,125)">Sorry to bring this thread from 3 months ago back, but I’m running into this issue too.</span><br>
<span style="color:rgb(31,73,125)">I do see that shouldIgnore is not called in the MachinePipeliner, however, James’ comment doesn’t really resolve the issue or make the story any clearer.</span><br>
<br>
<span style="color:rgb(31,73,125)">My summary of the comment is: “Hexagon and PPC9 do not need to ignore any instructions. However, in the case that you do, such as when the indvar update is explicit, this function is provided to allow the target to strip those
instructions from the pipelined kernel.”</span><br>
<br>
<span style="color:rgb(31,73,125)">However, the reality is that the implementation seems incomplete and there’s no instructions on how to achieve the desired result. Is it left as an exercise to the reader/implementer? Is there something I’m missing?</span><br>
<br>
<span style="color:rgb(31,73,125)">J.B. Nagurne</span><br>
<span style="color:rgb(31,73,125)">Code Generation</span><br>
<span style="color:rgb(31,73,125)">Texas Instruments</span><br>
<br>
<b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">mailto:llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>Jinsong Ji via llvm-dev<b><br>
Sent:</b> Tuesday, June 2, 2020 2:58 PM<b><br>
To:</b> Sander<b><br>
Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><b><br>
Subject:</b> [EXTERNAL] Re: [llvm-dev] Machinepipeliner interface. shouldIgnoreForPipelining, actually not ignoring.</span><u></u><u></u></p>
<p><span style="font-size:10pt">Hi Sander:</span><br>
<span style="font-size:10pt"><br>
It may be confusing, but it is not a bug. <br>
And you are right, if you are using the in-tree machinepipeliner, it won't have any effects,<br>
because there is NO In tree reference of this API at all.</span><br>
<span style="font-size:10pt"><br>
You can see the comments when </span>James<span style="font-size:10pt"> introduced this API in
</span><a href="https://reviews.llvm.org/D67167" target="_blank">https://reviews.llvm.org/D67167</a><br>
<br>
<span style="font-size:10pt"><br>
<br>
Best,<br>
<br>
Jinsong Ji (</span><span lang="ZH-CN" style="font-size:10pt;font-family:SimSun">纪金松</span><span style="font-size:10pt">), PhD.<br>
<br>
XL/LLVM on Power Compiler Development <br>
E-mail: <a href="mailto:jji@us.ibm.com" target="_blank">jji@us.ibm.com</a></span><br>
<br>
<b>Error! Filename not specified.</b><span style="font-size:10pt;color:rgb(66,66,130)">Sander via llvm-dev ---06/02/2020 03:47:53 PM---Hi all, I think there is a mistake in the machinepipeliner interface. In the</span><br>
<span style="font-size:10pt;color:rgb(95,95,95)"><br>
From: </span><span style="font-size:10pt">Sander via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><span style="color:rgb(95,95,95)"><br>
To: </span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><span style="color:rgb(95,95,95)"><br>
Date: </span>06/02/2020 03:47 PM<span style="color:rgb(95,95,95)"><br>
Subject: </span>[EXTERNAL] [llvm-dev] Machinepipeliner interface. shouldIgnoreForPipelining, actually not ignoring.<span style="color:rgb(95,95,95)"><br>
Sent by: </span>"llvm-dev" <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>></span><u></u><u></u></p>
<div>
<div>
<div class="MsoNormal">
<hr size="2" width="100%" noshade style="color:rgb(160,160,160)" align="left">
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
<br>
<br>
<span style="font-size:10pt"><br>
Hi all,<br>
<br>
I think there is a mistake in the machinepipeliner interface. In the <br>
TargetInstrInfo.h in the class PipelinerLoopInfo there is a function <br>
"bool shouldIgnoreForPipelining(const MachineInstr *MI)". The <br>
description says that if this function returns true for a given <br>
MachineInstr it will not be pipelined.<br>
<br>
However in reality it is not ignored and is being considered for <br>
pipelining. I implemented this function in my own backend, and put an <br>
instruction there that I want to be ignored, but still this instruction <br>
end up trying to be pipelined. I implemented the same way as in <br>
PPCInstrInfo.cpp, and I think it has the same bug. Is this a bug, or am <br>
I forgetting something?<br>
<br>
Kind regards,<br>
<br>
Sander Ruben<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><u><span style="color:blue"><br>
</span></u></span><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank"><span style="font-size:10pt">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</span></a><span style="font-size:10pt">
<br>
</span><br>
<br>
<u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote></div>