search for: vliws

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

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

Is there a VLIW support in LLVM? I found this, https://groups.google.com/forum/#!searchin/llvm-dev/VLIW, but it looks like it is not completely implemented. Specifically I'm interested in how instructions are bundled together. I can't seem to find it anywhere in the source code. Any help in resolving he issue is appreciated. -------------- next part -------------- An HTML attachment was

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, I notice that there exist some classes for VLIW packetizing and other classes for VLIW scheduling. Apparently these classes share something in common. Can someone explain why they should have separate implementation (i.e., in different function passes)? Best regards. -- 杨勇勇 (Yang Yongyong)

On Aug 9, 2012, at 10:09 AM, Sergei Larin <slarin at codeaurora.org> wrote: > Yang, > > This might not be such a tough choice on engineering side - one of the > LLVM differentiators is the ground-up, early introduced support for VLIW > specific features… Actually, LLVM lacked support for VLIW until fairly recently, and it has relatively few VLIW-specific features. Dan

Larin, Thank you for telling me about this. Our lab is planning to design a VLIW DSP and has to make a choice between GCC and LLVM, for which I take responsibility. As we all know that GCC's codes possess a long history and has a somewhat bad learning curve, I suggest choosing LLVM. It seems now the only drawback is its poor support for VLIW architecture. And so if we can count on

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

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 Yang, They have different implementations because they don't do the same thing and don't rely on the same structures. VLIW scheduling works on the SelectionDAG, right after the instruction selection, and it will schedule the DAG but it will not build any packet. The VLIW packetizer has been designed to work with machine instructions, using the ScheduleDAGInstr, and it does build

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,

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

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

Yang, This might not be such a tough choice on engineering side - one of the LLVM differentiators is the ground-up, early introduced support for VLIW specific features... As for the help offer - thanks... I'll definitely keep that in mind. The best help right now would be to keep on trying new VLIW related features as they got merged to LLVM tree and provide feedback... and we do plan to

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

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

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