[LLVMdev] making emitInlineAsm protected

[Rafael Espíndola]

On 31 January 2014 05:26, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> It may be moot because Reed is currently rewriting the patch to avoid using EmitInlineAsm and EmitRawText but I wanted to question something here.
>
> I'm thinking that hasRawTextSupport() shouldn't be the condition used inside EmitInlineAsm. I think it would be more correct to have a useRawTextSupport() predicate that can return hasRawTextSupport() for (sub)targets that haven't implemented their MC layer, and false for those that have. What do you think?

I generally agree. I would probably make it an independent "mature MC
support flag". I think that the current uses of hasRawTextSupport can
be classified into

* Comment printing. Should be moved APIs that only handle comment and
have a nop implementation on object streamers.
* Bits that have note been moved to MC yet. These need to be implemented.
* Some uses in debug printing I have not investigated yet :-)
* The one in EmitInlineAsm.

The one in EmitInlineAsm will probably be the last to go. The idea
behind it I think was that a target could implement object printing
but have inline asm still work with -S while the parser is finished. I
don't find it too convincing. The most likely reason for implementing
object emission for a target is to get "clang -c" (or llc
-filetype=obj) working, and that has to handle any inline asm it hits.

With an implementation like the one you describe, the development of
object emission for a given target would pass these stages.

* stage 0: llc -filetype=obj errors. No support has been implemented yet.
* stage 1: llc -filetype=obj tries to emit the object, but is know to
fail on some constructs (like inline assembly).
* stage 2: the streamer is declared mature. It is considered a bug for
it to fail. Clang would use this very same flag for deciding if it
would use the integrated assembler or not.

The big advantage would be that there would be no hasRawTextSupport in
the entire code base. For a triple in stage 1, filetype=obj would
always fail on inline assembly. For a triple in stage 2 even
filetype=asm would parse it.

Cheers,
Rafael