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

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

Mario,

On Nov 29, 2012, at 4:04 PM, Mario Guerra <mariog at codeaurora.org>
wrote:
> 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.
This is no different than any other MCInst in the course of object emission. 
Normal MCInst's are allocated on the stack in the AsmPrinter.
> 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?
There's no C++ style iterators, but there are perfectly-function C style
getNumOperands() and getOperand() methods.  It might be nice to add the former,
but you should be able to do everything you need with the latter.
> Those issues aside, it sounds like the streamer already understands how to
> process and print sub-instructions, which is good.
Actually, no.  The streamer knows nothing at all about sub-instructions. 
It's the responsibility of the printInstruction/encodeInstruction methods in
your printer or decoder know that they need to recurse onto the contents of the
bundle.
> Will the size of the
> packet be properly accounted for by the MCObjectStreamer if we have to pad
> the packet (mainly for fetch alignment)?
The MC system (including relaxation) is capable of handling instructions with
variable length encodings whose size can't be determined until the
MCCodeEmitter step.

--Owen

Owen,

On 11/29/12 18:16, Owen Anderson wrote:
>> Will the size of the
>> packet be properly accounted for by the MCObjectStreamer if we have to
pad
>> the packet (mainly for fetch alignment)?
> The MC system (including relaxation) is capable of handling instructions
with variable length encodings whose size can't be determined until the
MCCodeEmitter step.
Where could I find more information about how this is handled?

TIA

-- 
Evandro Menezes          Austin, TX          emenezes at codeaurora.org
Qualcomm Innovation Center, Inc is a member of the Code Aurora Forum

Owen,
> > 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.
> 
> This is no different than any other MCInst in the course of object
emission.  Normal
> MCInst's are allocated on the stack in the AsmPrinter.
That's the crux of our problem. The short lifespan of an MCInst prevents us
from being able to perform some of the optimizations we need at the MC level
that require the ability to traverse previous packets. We could do these
optimizations at the MI level before lowering, but then they would be missed
by the assembly parser since it goes directly to MC. 

Speaking of the assembly parser, we also need to be able build packets in
the parser. It currently operates on a single instruction at a time, so
building composite instructions in the parser would require some changes. I
don't know what those changes would look like yet, but it's worth
mentioning
in this context. 


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