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
On Mon, Sep 19, 2011 at 4:53 PM, Evandro Menezes <emenezes at codeaurora.org> wrote:> Has anyone attempted the port of LLVM to a VLIW architecture? Is there > any publication about it?http://blog.llvm.org/2010/06/tce-project-co-design-of-application.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-September/004800.html -Eli
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 takes operands from the MIs in the "slots" and transfers them to the superinstruction. From this point on the bundle is a normal machineinstruction which can be processed by other LLVM passes (such as register allocation). The idea was to make a framework on top of which VLIW/ILP scheduling could be studies using LLVM. It is not completely finished, but it is more or less usable and works with a trivial scheduler in a synthetic MIPS-VLIW architecture. Code emission does not work though (yet) so bundles have to be unpacked prior to emission. I was waiting to finish it to send a patch to the list, but if you are interested I can send you a patch over svn of my current code. BR Carlos
Carlos, On 09/20/11 09:02, Carlos Sánchez de La Lama wrote:> Hi, > > 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 takes operands from the MIs in the "slots" and transfers them to > the superinstruction. From this point on the bundle is a normal > machineinstruction which can be processed by other LLVM passes (such as > register allocation). > > The idea was to make a framework on top of which VLIW/ILP scheduling > could be studies using LLVM. It is not completely finished, but it is > more or less usable and works with a trivial scheduler in a synthetic > MIPS-VLIW architecture. Code emission does not work though (yet) so > bundles have to be unpacked prior to emission. > > I was waiting to finish it to send a patch to the list, but if you are > interested I can send you a patch over svn of my current code.This is rather interesting. Our VLIW architecture has variable size packets, in the sense that the shortest packet is a single instruction. Therefore, because packets can be formed at a later stage by bundling together instructions without data dependencies into a packet, I was thinking of perhaps splitting each MachineBasicBlock right before emitting the instructions so that each one will contain a packet. The next pass is to order the instructions in a packet properly. On the other hand, I'm not comfortable to "overload" existing structures to do things that they weren't meant to be used for. I think that your approach is better. Of course, I prefer to do all this in the MC layer, as this is the way to go forward. Thanks, -- 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 the test scheduler is just provided as an example. Main thing still missing is to finish the "pack" and "unpack" methods in the bundle class. Right now it manages operands, both implicit and explicit, but it should also manage memory references, and update MIB flags acording to sub-MI flags. For any question I would be glad to help. BR Carlos On Tue, 2011-09-20 at 16:02 +0200, Carlos Sánchez de La Lama wrote:> 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 takes operands from the MIs in the "slots" and transfers them to > the superinstruction. From this point on the bundle is a normal > machineinstruction which can be processed by other LLVM passes (such as > register allocation). > > The idea was to make a framework on top of which VLIW/ILP scheduling > could be studies using LLVM. It is not completely finished, but it is > more or less usable and works with a trivial scheduler in a synthetic > MIPS-VLIW architecture. Code emission does not work though (yet) so > bundles have to be unpacked prior to emission. > > I was waiting to finish it to send a patch to the list, but if you are > interested I can send you a patch over svn of my current code. > > BR > > Carlos-------------- next part -------------- A non-text attachment was scrubbed... Name: llvm_vliw.patch Type: text/x-patch Size: 17410 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111006/83b22b3a/attachment.bin>