similar to: Understanding and Cleaning Up Machine Instruction Bundles

> On Oct 27, 2016, at 2:33 PM, Matthias Braun <mbraun at apple.com> wrote: > > == BUNDLE instruction / operands == > For many backend passes a bundle can appear as a single unit. However one important tool > here is having an iterator over all operands of this unit. > > The original RFC indicates that to achieve this without changing a big number > of passes an

On 10/27/2016 4:33 PM, Matthias Braun via llvm-dev wrote: > > In fact I am not sure why you would even wait with the finalization and do it > in a separate pass rather than doing it immediately after forming the bundle. > Using the pass today does not even work as the MachineVerifier will reject the > intermediate unfinalized state (missing internal read markers). I'd suggest to

> On Oct 27, 2016, at 5:05 PM, Andrew Trick <atrick at apple.com> wrote: > > >> On Oct 27, 2016, at 2:33 PM, Matthias Braun <mbraun at apple.com> wrote: >> >> == BUNDLE instruction / operands == >> For many backend passes a bundle can appear as a single unit. However one important tool >> here is having an iterator over all operands of this

> On Oct 27, 2016, at 5:30 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On Oct 27, 2016, at 5:05 PM, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote: >> >>> The system works because the default basic block iterator moves from bundle to >>> bundle skipping the instructions inside the bundle. Iterating

> On Oct 27, 2016, at 5:23 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 10/27/2016 4:33 PM, Matthias Braun via llvm-dev wrote: >> >> In fact I am not sure why you would even wait with the finalization and do it >> in a separate pass rather than doing it immediately after forming the bundle. >> Using the pass today does not

Hi Evan, I just read your proposal and the following discussion for VLIW support and want to share my experience of writing a VLIW back-end for LLVM. I would not integrate the packetizer into the register allocator super class since it would reduce the flexibility for the back-end developer to add some optimization passes after the packetizer. Instead, I would add the packetizer as a separate

On Thu, Mar 29, 2012 at 03:51:10PM -0700, Andrew Trick wrote: > > On Mar 29, 2012, at 1:18 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > > > On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > >> Tom, > >> > >> I do not have your call stack, but packetizer calls > >> ScheduleDAGInstrs::buildSchedGraph to create

Machine Instruction Bundle in LLVM Hi all, There have been quite a bit of discussions about adding machine instruction bundle to support VLIW targets. I have been pondering what the right representation should be and what kind of impact it might have on the LLVM code generator. I believe I have a fairly good plan now and would like to share with the LLVM community. Design Criteria 1. The

. and yes, one more thing. On some architectures it might be desirable to know the _order_ of instructions in the packet. That is a bit trickier.. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Friday, December 02, 2011 2:40 PM To: LLVM Dev Subject: [LLVMdev]

On Dec 2, 2011, at 2:41 PM, Sergei Larin wrote: > … and yes, one more thing. On some architectures it might be desirable to know the _order_ of instructions in the packet. That is a bit trickier…. Isn't that just the order of the instructions in the list? I don't see anything that prevents getting the order of instructions. It might require iterator over MIs in the packet. But for

Evan, I will need to comprehend it better, but one small comment right away. Did we not discuss one more option for bundle implementation - global cycle ID. We would add an unsigned int field to MI definition representing "global scheduling cycle". All MIs with the same global cycle value belong to one group/packet. Zero means unscheduled MI. That is light weight,

On Oct 25, 2011, at 1:59 AM, Stripf, Timo wrote: > Hi all, > >> Ok, so in your proposal a bundle is just a special MachineInstr? That sounds good. How are the MachineInstr's embedded inside a bundle? How are the cumulative operands, implicit register defs and uses represented? > > I attached the packing and unpacking pass I used within my backend. In my solution multiple

On Oct 24, 2011, at 2:38 PM, Carlos Sánchez de La Lama wrote: > Hi Evan (and all), > >> I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. > > The approach in the patch I sent (and I believe Timo's code works similar,

Hi all, > Ok, so in your proposal a bundle is just a special MachineInstr? That sounds good. How are the MachineInstr's embedded inside a bundle? How are the cumulative operands, implicit register defs and uses represented? I attached the packing and unpacking pass I used within my backend. In my solution multiple MachineInstruction are packed into one variadic "PACK"

Evan, What would change if tomorrow we got a VLIW target/back end with some certain properties - let's say no intra-packed deps - would it sway your opinion in either direction? Would it be a natural prerogative to implement it certain way for such hypothetical contributor/submitter? Thanks. Sergei Larin -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu

Hi Timo, I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. Furthermore, if this is something that no current targets are using, then it cannot be adopted into LLVM mainline. I think what we need is a concept of a sequence of fixed machine

Hi Evan (and all), > I think any implementation that makes a "bundle" a different entity from MachineInstr is going to be difficult to use. All of the current backend passes will have to taught to know about bundles. The approach in the patch I sent (and I believe Timo's code works similar, according to his explanations) is precisely to make "bundles" no different

Hi all, I worked the last 2 years on a LLVM back-end that supports clustered and non-clustered VLIW architectures. I also wrote a paper about it that is currently within the review process and is hopefully going to be accepted. Here is a small summary how I realized VLIW support with a LLVM back-end. I also used packing and unpacking of VLIW bundles. My implementations do not require any

Evan, Timo, Carlos (and everyone else), I have somewhat similar interest. What would you say to a some sort of a "global cycle" field/marker to determine all instructions scheduled at a certain "global" cycle. That way the "bundle"/packet/multiop can be identified at any time via a common "global cycle" value. I could see that being set first in pre-ra

Hi all, here is the current (unfinished) version of the VLIW support I mentioned. It is a patch over svn rev 141176. It includes the MachineInstrBundle class, and small required changes in a couple of outside LLVM files. Also includes a modification to Mips target to simulate a 2-wide VLIW MIPS. The scheduler is really silly, I did not want to implement a scheduler, just the bundle class, and