similar to: Branches which return values in SelectionDAG

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

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

Invitation accepted, I am happy to help out with reviews, like I did with the previous VP patches. And of course agreed that things should be well defined, and that we shouldn't paint ourselves in a corner, but I don't think that this is the case. And it's not that I am in a rush, but I don't think this change needs to be predicated on a big change landing first like the LV

After playing a bit with the newly introduced hardware loop framework I realize that the llvm.set.loop.iterations intrinsic takes as argument the number of iterations the loop will execute. In fact it goes all the way to, on IR, insert an addition of constant 1 to the number of taken backedges returned by SCEV. If the machine instruction realizing the loop is interested in the number of

> You have similar problems with https://reviews.llvm.org/D79100 The new revision D79100<https://reviews.llvm.org/D79100> solves your comment 1), and I don't think your comments2) and 3) apply as there are no vendor specific intrinsics involved at all here. Just to quickly discuss the optimisation pipeline, D79100<https://reviews.llvm.org/D79100> is a small extension for the

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

Hi Simon, Thanks for reposting the example, and looking at it more carefully, I think it is very similar to my first proposal. This was met with some resistance here because it dumps loop information in the vector preheader. Doing it this early, we want to emit this in the vectoriser, puts a restriction on (future) optimisations that transform vector loops to honour/update/support this intrinsic

Hi, I abandoned that approach and followed Eli's suggestion, see somewhere earlier in this thread, and emit an intrinsic that represents/calculates the active mask. I've just uploaded a new revision for D79100 that implements this. Cheers. ________________________________ From: Simon Moll <Simon.Moll at EMEA.NEC.COM> Sent: 18 May 2020 13:32 To: Sjoerd Meijer <Sjoerd.Meijer at

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

Hi Roger, That's a good example, that shows most of the moving parts involved here. In a nutshell, the difference is, and what we would like to make explicit, is the vector trip versus the scalar loop trip count. In your IR example, the loads/stores are predicated on a mask that is calculated from a splat induction variable, which is compared with the vector trip count. Illustrated with your

Hi, Gang: I remember there were different voices when you check-in the code. I agree with them although I didn't reply your mail in open64's mailing list. In the transformation you illustrate, it involves two operations: 1) promote WHILE-loop into DO-loop (i.e noncountable loop to countable loop) 2) get rid of trip-count dec/inc and compare. 1) is irrelevant to HW loop.

> The harm comes if the intrinsic ends up with the wrong value, or attached to the wrong loop. The intrinsic is marked as IntrNoDuplicate, so I wasn't worried about it ending up somewhere else. Also, it is a property of a specific loop, a tail-folded vector loop, that holds even after it is transformed I think. I.e. unrolling a vector loop is probably not what you want, but even if you do

Hi Shuxin, Eli, On 22/11/2012 03:19, Shuxin Yang wrote: > Hi, Ivan: > > My $0.02. hasZeroCostLooping() disabling unrolling dose not seem > to be > appropriate for other architectures, at least the one I worked before. I appreciate your feed-back. Could you give an example where building a hw loop is not appropriate for your target? > > You mentioned: >

I am the designer for open64 hwloop structure, but I am not a student. Hope the following helps: To transform a loop into hwloop, we need the help from optimizer. For example, while(k3>=10){ sum+=k1; k3 --; } into the form: zdl_loop(k3-9) { sum+=k1; } So, we introduce a new ZDLBR whirl(open64 optimizer intermediate) operator, which represents the loop in whirl as:

Hi shuxin, Promote while-loop to do-loop is the job of loop induction recognized, not this transformation. The scalar transform for hwloop in optimizer is for that it is a trouble to discriminate trip counting code with the real production code stuff and do the elimination in cg, we have to write customized code to handle this general stuff in ervey targets. So, we take the help from optimizer

Hi, Gang: I don't want to discuss Open64 internal in LLVM mailing list. Let us only focus on the design per se. As your this mail and your previous mail combined give me a impression that : The only reason you introduce the specific operator for HW loop in Scalar Opt simply because you have hard time in figure out the trip count in CodeGen. This might be true for Open64's

I spent some time digging into a Valgrind report of uninitialized values in LLVM r287520 built using itself. (One of quite a few such reports that comes up during a "make check".) I could use another set of eyes on the issue if someone has time. This command gives me an error: valgrind -q ./bin/llc < /home/regehr/llvm/test/CodeGen/Hexagon/hwloop-dbg.ll -march=hexagon

Hi Eli, > The problem with your proposal, as written, is that the vectorizer is producing the intrinsic. Because we don’t impose any ordering on optimizations before codegen, every optimization pass in LLVM would have to be taught to preserve any @llvm.set.loop.elements.i32 whenever it makes any change. This is completely impractical because the intrinsic isn’t related to anything

Hi Shuxin, On 23/11/2012 00:17, Shuxin Yang wrote: > Hi, Gang: > > I don't want to discuss Open64 internal in LLVM mailing list. Let us > only focus on the design per se. > As your this mail and your previous mail combined give me a impression > that : > > The only reason you introduce the specific operator for HW loop in > Scalar Opt simply because >

Hello, We are working on predication for our vector extension (MVE). Since quite a few people are working on predication and different forms of it (e.g. SVE, RISC-V, NEC), I thought I would share what we would like to add to the loop vectoriser. Hopefully it's just a minor one and not intrusive, but could be interesting and useful for others, and feedback on this is welcome of course. TL;DR: