llvm dev - Nov 2012 - [LLVMdev] Support for bundles of MCInst?

Hello all, 

We're developing an integrated assembler for a VLIW target, and some of the
optimizing our assembler needs to do must be done on a per-packet basis.
This requires us to be able to traverse instruction within a packet, and one
particular optimization requires traversal of previous packets as well. 

We're considering adding support for MCInst bundles in the MC layer to
accommodate this use case, analogous to what currently exists for
MachineInstr. Has anyone given thought to this before? Is there already a
way to create bundles in the MC layer that we've overlooked? 

Any comments or suggestions are appreciated. 

Thanks,

On Thu, Nov 29, 2012 at 3:00 PM, Mario Guerra <mariog at codeaurora.org>
wrote:
> Hello all,
>
> We're developing an integrated assembler for a VLIW target, and some of
the
> optimizing our assembler needs to do must be done on a per-packet basis.
> This requires us to be able to traverse instruction within a packet, and
one
> particular optimization requires traversal of previous packets as well.
>
> We're considering adding support for MCInst bundles in the MC layer to
> accommodate this use case, analogous to what currently exists for
> MachineInstr. Has anyone given thought to this before? Is there already a
> way to create bundles in the MC layer that we've overlooked?
>
> Any comments or suggestions are appreciated.
>
Could you elaborate on this proposal in a bit more detail? What will
the semantics of these MCInst bundles be, how will they be generated,
and what special treatment will they get from the assembler?

Thanks in advance,
Eli

Mario,

On Nov 29, 2012, at 3:00 PM, Mario Guerra <mariog at codeaurora.org>
wrote:
> We're developing an integrated assembler for a VLIW target, and some of
the
> optimizing our assembler needs to do must be done on a per-packet basis.
> This requires us to be able to traverse instruction within a packet, and
one
> particular optimization requires traversal of previous packets as well. 
> 
> We're considering adding support for MCInst bundles in the MC layer to
> accommodate this use case, analogous to what currently exists for
> MachineInstr. Has anyone given thought to this before? Is there already a
> way to create bundles in the MC layer that we've overlooked? 
There should already be sufficient support for what you're trying to do. 
See MCOperand::CreateInst().  The concept is that you'll build a composite
MCInst in your AsmPrinter::EmitInstruction() method, which uses Inst-type
MCOperands to hold a list of sub-instructions.  Then you call
AsmStreamer::EmitInstruction() on the composite MCInst.

--Owen

Hello Eli, 
> Could you elaborate on this proposal in a bit more detail? What will the
semantics
> of these MCInst bundles be, how will they be generated, and what special
> treatment will they get from the assembler?
Thanks for your reply. There is no proposal as of yet, I first wanted to
check and see if a) there was already a way to do this in the MC layer, and
b) if not, if anyone had already come up with ideas on how to approach it. 

- --
Mario Guerra
mariog at codeaurora.org
Qualcomm Innovation Center Inc is a member of Code Aurora Forum, hosted by
The Linux Foundation

Hello Owen,
> There should already be sufficient support for what you're trying to
do.
See
> MCOperand::CreateInst().  The concept is that you'll build a composite
MCInst in
> your AsmPrinter::EmitInstruction() method, which uses Inst-type MCOperands
to
> hold a list of sub-instructions.  Then you call
AsmStreamer::EmitInstruction() on the
> composite MCInst.
Thanks for your reply. This is actually one approach we are considering, but
there are a few issues with it we weren't sure how to address. 

One is that the lifespan of an MCInst seems to be limited to the scope of
AsmPrinter, and we need them to be persistent in order to do a traversal for
branch relaxation and fetch boundary alignment optimizations. Furthermore,
even if they were persistent there doesn't seem to be a way to traverse
MCInst objects due to a lack of iterator support. Have we overlooked this
functionality? If not, does it make sense for us to add it?

Those issues aside, it sounds like the streamer already understands how to
process and print sub-instructions, which is good. Will the size of the
packet be properly accounted for by the MCObjectStreamer if we have to pad
the packet (mainly for fetch alignment)?

Thanks,
- --
Mario Guerra
mariog at codeaurora.org
Qualcomm Innovation Center Inc is a member of Code Aurora Forum, hosted by
The Linux Foundation