search for: vliw

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 that uses it (can some dev confirm this?). My backend is still on the works, I have only a synthetic MIPS-VLIW working backend, but that is not a real target. Is your code public, or plan to be? BR Carlo...

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

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

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

...nt a number of MachineInstr's that are scheduled as a unit, something that is never broken up by MI passes such as branch folding. This is something that current targets can use to, for example, pre-schedule instructions. This can be useful for macro-fusing optimization. It can also be used for VLIW targets. Evan On Oct 21, 2011, at 4:52 PM, Stripf, Timo wrote: > 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...

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

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

...nt a number of MachineInstr's that are scheduled as a unit, something that is never broken up by MI passes such as branch folding. This is something that current targets can use to, for example, pre-schedule instructions. This can be useful for macro-fusing optimization. It can also be used for VLIW targets. There might be something I am missing, but I do not see the advantage here. Even more, if you use sequences you need to find a way to tell the passes how long a sequence is. On the other hand, if you use a class derived from MI, the passes know already (from their POV their are just deali...

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 packets (not scheduling). Both impl...

...nt a number of MachineInstr's that are scheduled as a unit, something that is never broken up by MI passes such as branch folding. This is something that current targets can use to, for example, pre-schedule instructions. This can be useful for macro-fusing optimization. It can also be used for VLIW targets. > > There might be something I am missing, but I do not see the advantage here. Even more, if you use sequences you need to find a way to tell the passes how long a sequence is. On the other hand, if you use a class derived from MI, the passes know already (from their POV their are...

...lacement of this marker - I am not sure yet, but MachineInstr sure must have one, but as early as SUnit in DAG->DAG Pattern Instruction Selection we should be able to do that. This is a trivial solution that seems to provide required functionality in the least intrusive way, and useful to non-VLIW architectures to convey pre-schedule information down flow. Sergei Larin -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Carlos Sánchez de La Lama Sent: Monday, October 24, 2011 4:38 PM To: Evan Cheng Cc: Stripf, Timo; LLVM Dev...

...killed. Carlos > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Carlos Sánchez de La Lama > Sent: Monday, October 24, 2011 4:38 PM > To: Evan Cheng > Cc: Stripf, Timo; LLVM Dev > Subject: Re: [LLVMdev] VLIW Ports > > 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...

...elegant to use a derived class of MachineInstr for storing multiple instructions into one. Here are my thoughts on instruction bundle. First, let's talk about the prerequisite for adding a codegen level IR extension. A MachineInstr bundle should be generic enough to support the followings 1) VLIW bundles (where there are no intra-dependencies between instructions in a bundle), 2) bundles for other targets where there may be intra-dependencies between instructions in a bundle. #2 is very important for the extension to be accepted into LLVM mainline today since there are no proper VLIW target...

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 contribute a lot in the next several weeks/months. Al...

...lass of MachineInstr for storing multiple instructions into one. Best regards, Timo Stripf -----Ursprüngliche Nachricht----- Von: Evan Cheng [mailto:evan.cheng at apple.com] Gesendet: Dienstag, 25. Oktober 2011 01:55 An: Carlos Sánchez de La Lama Cc: Stripf, Timo; LLVM Dev Betreff: Re: [LLVMdev] VLIW Ports 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 kno...

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: l...

...last pass, right before code emission is still needed to "clean up" the final schedule. I do not have a patch handy, it would have been easier to illustrate my proposal, but the fact of this discussion alone shows growing interest to the problem. I have a feeling that we might obtain a VLIW target/back end shortly, and then it would become a real (and burning) issue. This might be our chance to outperform GCC RISC centric philosophy in an elegant and powerful way. First step to healing is to recognize that we have an issue ;) Sergei -----Original Message----- From: Carlos Sánche...

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