similar to: [LLVMdev] RFC: Machine Instruction Bundle

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

. 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,

Hi, I'm glad to see some action with regard to static instruction scheduling and VLIW support in LLVM. I have some questions and remarks which might not be relevant as I'm not totally familiar with the current code generation framework of LLVM nor your plan. On 12/02/2011 10:40 PM, Evan Cheng wrote: > 2. It must be flexible enough to represent more than VLIW bundles. It should be >

Hi paulr, Thank you for your response :) Hi Krzysztof, This is really helpful! Thank you for your guidance!! I would like to trace the Hexagon's llvm implementation. I am very interested on how Hexagon implement instruction pattern matching, instruction scheduling, and register allocation, could you give me some suggestions or reading lists to help me understand Hexagon's llvm

On Dec 2, 2011, at 12:40 PM, Evan Cheng wrote: > 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. Let me add some

Hi Sergei, Jakob, Thanks for your comments ! On 07/06/2012 20:41, Sergei Larin wrote: > > Jakob, > > Please see my comments below. Hope this helps. > > Sergei > > -- > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > > *From:*Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > *Sent:* Thursday, June 07, 2012 1:02 PM > *To:* Sergei

Hello, I want to implement LLVM backend for a specific VLIW hardware. I am working on defining its instruction set, and assembly language. The hardware has two pipelines, int and float. Each pipeline can do 3 operations/cycle, 3 operations forms an instruction. One of the Integer Instruction looks like this: add Ri, Rj, Rk; add Rl, Rm, Rn; add Ro, Rp, Rq An int instruction and a float

Hi again! On 08/06/2012 17:11, Ivan Llopard wrote: > Hi Sergei, Jakob, > > Thanks for your comments ! > > On 07/06/2012 20:41, Sergei Larin wrote: >> >> Jakob, >> >> Please see my comments below. Hope this helps. >> >> Sergei >> >> -- >> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. >>

On Jun 7, 2012, at 10:25 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Generally as far as I concern, there is no way “generic” (platform independent) code can add instructions to bundles optimally I agree, there are too many ways of modeling stuff with bundles. That is why I took the philosophical stance of treating bundles as black boxes during RA. I think the

Hi, I am planning to expanding the pseudo instructions in XXXTargetLowering::EmitInstrWithCustomInserter(), and use temporary virtual registers as operands. If I use virtual registers, do I need to mark them as "early clobber"? I saw that sometimes they marked virtual register as "early clobber" in EmitInstrWithCustomInserter() in MIPS backend. What is the effect of marking a

Jakob, Please see my comments below. Hope this helps. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: Thursday, June 07, 2012 1:02 PM To: Sergei Larin Cc: 'Ivan Llopard'; 'LLVM Developers Mailing List' Subject: Re: [LLVMdev] Instruction bundles before RA: Rematerialization

Carlos, Absolutely. And an addition to live range detection needs to be made aware of the global cycle... and it needs to be done regardless of representation methodology. Same for any pass that would care for packets. The important observation here IMHO is that "packetization" at early stage (before RA) is tentative, and RA can change the landscape, which must be somewhat finalized

On 12/05/2011 11:50 PM, Jakob Stoklund Olesen wrote: > By adding a new<internal> flag to MachineOperand, the register allocator can > effectively treat a bundle as a single instruction. All MachineOperands > inside a bundle are treated as if they all belong to the single instruction. > This even works when rewriting operands. This sounds like a simple and good solution to the

Dave, Thank you for your interest. Please see my replies below. Sorry that my terminology is not as crisp as Andy's, but I think you can see what I mean. Sergei -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum. > -----Original Message----- > From: dag at cray.com [mailto:dag at cray.com] > Sent: Friday, May 11, 2012 12:14 PM > To: Sergei Larin > Cc:

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 Sergei, > 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. But RA would need to know about this global cycle field, right? Cause a register can be

It seems to me that the concept of insn bundles or packets is needed with different characteristics, depending where it's used. At early scheduling, when there may be no MachineInstruction objects yet, the data structure or annotation that's needed may be quite different from that needed at or near code generation and emission. I think that what Sergei is talking about fits well with

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