[LLVMdev] issues with InlineAsm class and #APP/#NOAPP

[Rafael Espíndola]

> We also wanted the stubs to be real functions to llvm. That allows them to
> participate properly
> in optimization of various levels (including LTO). They can even be inlined.
> There are other
> planned optimizations that would not work if they were not legitimate
> functions.

I am not saying that the functions should not exist in the IL, just
that they should not be inline assembly.

> Arm does not have this ability to compile both thumb1 and ARM
> functions in the same source file in LLVM so they would not have had the
> option to do this in the IR.

But llvm has to represent it when one IL file with thumb and one with
ARM code are linked. I think this was one of the motivations for the
current work on extending attributes.

> I'm almost done now and not going to revisit the whole design at this point.

Which is a reason why design issues like this should be discussed
early. Was there an email about having the frontend emit inline
assembly early on? If so, sorry I missed it.

I still don't think we should have code where the FE emits inline
assembly. Anything that clang can know about mips16/mips32, llvm can
too. If llvm knows it, all that should be necessary is an attribute in
the function saying "this is a mips32 stub".

> The only annoying part are these #APP/#NOAPP wrappers.

Cheers,
Rafael