similar to: [LLVMdev] VLIW Ports

Hi, > Has anyone attempted the port of LLVM to a VLIW architecture? Is there > any publication about it? I have developed a derivation of MachineInstr class, called MachineInstrBundle, which is essnetially a VLIW-style machine instruction which can store any MI on each "slot". After the scheduling phase has grouped MIs in bundles, it has to call MIB->pack() method, which

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

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

Hi Timo, your approach is quite similar to the one in the patch I sent a couple of weeks ago. I also have the Bundle (derivate from MachineInstruction so I call it "MachineInstructionBundle") and pack/unpack so RegAlloc works on the bundles… I really think this is the way to incorporate VLIW support to LLVM. I guess a need for some of this to make to LLVM trunk is to have a backend

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

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

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

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

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

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

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"

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

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 Carlos, I am interested in your port of a MIPS-VLIW architecture. I plan to use a similar one for which there is no LLVM backend yet. Have you some example of your code? Best, Julien. On 22/10/11 11:10 , Carlos Sánchez de La Lama wrote: > Hi Timo, > > your approach is quite similar to the one in the patch I sent a couple of weeks ago. I also have the Bundle (derivate from

I'd appreciate some help in figuring out how to determine which InstrItinClass an instruction belongs to. For example, an InstrItinClass is defined in Schedule.td as: def FOO : InstrItinClass; Which is then used to build an InstrItinData in ProcessorItineraries and to specify the class of a particular instruction. I'd like to find out from a given instruction which class it belongs

hi guys I need to get llvm to support vliw architecture. Can you please point me in the right direction. we have managed to get it to compile into simple assemble and now need it to be able to schedule the instructions in parrallel. any help would be appreciated Regards Junior

On 08/21/12 16:49, Jim Grosbach wrote: > > I like that. Possibly with the addition that we can filter by a specific property. -Winfer=neverHasSideEffects, e.g., would only show when that specific property is inferred. > > Beyond that, I don't see an alternative to an audit of the instructions that get flagged by such a warning. :( This proposal would certainly make my life easier

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 >

On Fri, Mar 2, 2012 at 11:32 AM, Evandro Menezes <emenezes at codeaurora.org> wrote: ... > Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not > normative. See foot note 7 in the same page. Figure 3.4 on page 21 > confirms that the use of a frame-pointer is optional. > > So, if one doesn't use ENTER in the prologue and uses RSP to access local >