[llvm-dev] [EXTERNAL] RE: Machinepipeliner interface. shouldIgnoreForPipelining, actually not ignoring.

Wed Sep 9 00:08:04 PDT 2020

Hi James,

One last thing - is your target upstream? or are you working on a
downstream target?

Cheers,

James

On Tue, 8 Sep 2020 at 23:02, Nagurne, James <j-nagurne at ti.com> wrote:

> I greatly appreciate you going back to gather that intel, James. It
> actually helps my understanding of the whole pipeliner puzzle quite a bit!
>
>
>
> 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 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
> https://reviews.llvm.org/D53005, 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.
>
>
>
> 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! J
>
>
>
> Thanks again!
>
>
>
> JB
>
>
>
> *From:* James Molloy [mailto:jmolloy at google.com]
> *Sent:* Monday, September 7, 2020 1:49 AM
> *To:* Nagurne, James
> *Cc:* Jinsong Ji; llvm-dev at lists.llvm.org; Sander; Hendrik Greving
> *Subject:* Re: [EXTERNAL] RE: [llvm-dev] Machinepipeliner interface.
> shouldIgnoreForPipelining, actually not ignoring.
>
>
>
> Hi James,
>
>
>
> Having not worked on this for circa one year I've gone and refreshed my
> memory.
>
>
>
> 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.
>
>
>
> 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".
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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).
>
>
>
> Cheers,
>
>
>
> James
>
>
>
> On Thu, 3 Sep 2020 at 20:41, Nagurne, James <j-nagurne at ti.com> wrote:
>
> 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):
>
>
>
> %body:
>
> *                %indvar = PHI(%init, %preheader, %dec, %body)*
>
>                 …
>
> *                %dec = subtract %indvar, count*
>
>                 branch-compare (%dec > 0), %body
>
>                 branch %end
>
> %end:
>
>                 …
>
>
>
> 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! J
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> JB
>
>
>
> *From:* James Molloy [mailto:jmolloy at google.com]
> *Sent:* Thursday, September 3, 2020 2:07 PM
> *To:* Nagurne, James
> *Cc:* Jinsong Ji; llvm-dev at lists.llvm.org; Sander; Hendrik Greving
> *Subject:* Re: [EXTERNAL] RE: [llvm-dev] Machinepipeliner interface.
> shouldIgnoreForPipelining, actually not ignoring.
>
>
>
> Hi James,
>
>
>
> Adding Hendrik, who has taken over ownership of the downstream code
> involved.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> James
>
>
>
> On Thu, 3 Sep 2020, 17:19 Nagurne, James, <j-nagurne at ti.com> wrote:
>
> 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!
>
>
>
> Since he’s on the email thread now:
>
>
>
> 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.
>
>
>
> JB
>
>
>
> *From:* Jinsong Ji [mailto:jji at us.ibm.com]
> *Sent:* Thursday, September 3, 2020 10:03 AM
> *To:* Nagurne, James; jmolloy at google.com
> *Cc:* llvm-dev at lists.llvm.org; Sander
> *Subject:* [EXTERNAL] RE: [llvm-dev] Machinepipeliner interface.
> shouldIgnoreForPipelining, actually not ignoring.
>
>
>
> As I mentioned before,
> this API was introduced by James, mostly for his out-of-tree
> implementations,
> the in tree implementation NEVER implement it.
>
> If it is causing confusion, I think we have two choices:
> 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.
> 2. Remove this confusing API in tree.
>
>
> Best,
>
> Jinsong Ji (纪金松), PhD.
>
> XL/LLVM on Power Compiler Development
> E-mail: jji at us.ibm.com
>
> *Error! Filename not specified.*"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
>
> From: "Nagurne, James" <j-nagurne at ti.com>
> To: Jinsong Ji <jji at us.ibm.com>, Sander <sanderruben at gmail.com>
> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
> Date: 09/02/2020 01:43 PM
> Subject: RE: [EXTERNAL] Re: [llvm-dev] Machinepipeliner interface.
> shouldIgnoreForPipelining, actually not ignoring.
> ------------------------------
>
>
>
>
> Sorry to bring this thread from 3 months ago back, but I’m running into
> this issue too.
> 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.
>
> 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.”
>
> 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?
>
> J.B. Nagurne
> Code Generation
> Texas Instruments
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org
> <llvm-dev-bounces at lists.llvm.org>] *On Behalf Of *Jinsong Ji via llvm-dev
> * Sent:* Tuesday, June 2, 2020 2:58 PM
> * To:* Sander
> * Cc:* llvm-dev at lists.llvm.org
> * Subject:* [EXTERNAL] Re: [llvm-dev] Machinepipeliner interface.
> shouldIgnoreForPipelining, actually not ignoring.
>
> Hi Sander:
>
> It may be confusing, but it is not a bug.
> And you are right, if you are using the in-tree machinepipeliner, it won't
> have any effects,
> because there is NO In tree reference of this API at all.
>
> You can see the comments when James introduced this API in
> https://reviews.llvm.org/D67167
>
>
>
> Best,
>
> Jinsong Ji (纪金松), PhD.
>
> XL/LLVM on Power Compiler Development
> E-mail: jji at us.ibm.com
>
> *Error! Filename not specified.*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
>
> From: Sander via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Date: 06/02/2020 03:47 PM
> Subject: [EXTERNAL] [llvm-dev] Machinepipeliner interface.
> shouldIgnoreForPipelining, actually not ignoring.
> Sent by: "llvm-dev" <llvm-dev-bounces at lists.llvm.org>
> ------------------------------
>
>
>
>
>
> Hi all,
>
> I think there is a mistake in the machinepipeliner interface. In the
> TargetInstrInfo.h in the class PipelinerLoopInfo there is a function
> "bool shouldIgnoreForPipelining(const MachineInstr *MI)". The
> description says that if this function returns true for a given
> MachineInstr it will not be pipelined.
>
> However in reality it is not ignored and is being considered for
> pipelining. I implemented this function in my own backend, and put an
> instruction there that I want to be ignored, but still this instruction
> end up trying to be pipelined. I implemented the same way as in
> PPCInstrInfo.cpp, and I think it has the same bug. Is this a bug, or am
> I forgetting something?
>
> Kind regards,
>
> Sander Ruben
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200909/3a0ce153/attachment-0001.html>