[LLVMdev] VLIW Ports

Evandro Menezes emenezes at codeaurora.org
Mon Sep 26 12:16:25 PDT 2011


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




More information about the llvm-dev mailing list