[LLVMdev] Support for bundles of MCInst?

[Owen Anderson]

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