search for: machineinstrbundles

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

Has anyone attempted the port of LLVM to a VLIW architecture? Is there any publication about it? TIA -- Evandro Menezes Austin, TX emenezes at codeaurora.org Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

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, One of the long-standing code clean-up bugs in Bugzilla is to extract the Machine* code from the CodeGen library into a separate one, on which CodeGen depends ( http://llvm.org/bugs/show_bug.cgi?id=1121). I'd like to start working on this. The general approach I'm planning to take is: 1. Identify which code to move. 2. Eliminate all dependencies that the Machine code has on the

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote: > Hi, > > One of the long-standing code clean-up bugs in Bugzilla is to extract > the Machine* code from the CodeGen library into a separate one, on > which CodeGen depends ( > http://llvm.org/bugs/show_bug.cgi?id=1121). > > I'd like to start working on this. The general approach I'm planning

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

...sure that CCR is never live. I can use pseudo-instructions to bundle cmp+jump but it's not ideal because I might also have to bundle cmp+jump+jump+... into a pseudo. Also, there are several flavours of cmp instruction so I might need a lot of pseudos. That's what led me to wonder whether MachineInstrBundles might be a neater solution but I wasn't sure whether they were really intended, or suitable, for this purpose. Steve On 3 Jun 2013, at 17:30, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 3, 2013, at 6:05 AM, Steve Montgomery <stephen.montgomery3 at btinternet....

Hi, On 12/07/2011 01:10 AM, Krzysztof Parzyszek wrote: > Another approach would be to have a pseudo-instruction (say, "macro"), > which would be associated with a sequence of instructions, which have > been outlined, and which have been replaced by the "macro" instruction. > The "macro" instruction would have the information about registers used > and

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

...ver live. > > I can use pseudo-instructions to bundle cmp+jump but it's not ideal because I might also have to bundle cmp+jump+jump+... into a pseudo. Also, there are several flavours of cmp instruction so I might need a lot of pseudos. > > That's what led me to wonder whether MachineInstrBundles might be a neater solution but I wasn't sure whether they were really intended, or suitable, for this purpose. That might be possible, at least the register allocator understands bundles. Passes before register allocation are not bundle aware, including the MI scheduler. You may be able to fo...

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

I just signed up to this mailing list so I don't have the original email with the proposal to reply to. I got the text forwarded to me though, and here are my thoughts on it: - The requirement that it should be easy for a pass to be oblivious to bundles isn't well defined. If this means that a pass should be able to run as if the bundles weren't present, then such a pass can easily

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

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

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

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

...4. The representation should make it easy for new code to be oblivious of bundles. That is, MI passes should not have to check whether something is a bundle. Given the above, we can rule out a new class (e.g. MachineInstrBundle) right away. We don't want MachineBasic block to keep a list of MachineInstrBundles since it will require massive amount of code change. So what are the choices? Bundle Representation 1. A nested MachineInstr: This is the most natural (meaning it looks most like the real HW bundle) representation. It has the nice property that most passes do not have to check if a MI is a...

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"