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

[reed kotler]

On 04/24/2013 04:25 PM, Rafael Espíndola wrote:
>> 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.
Well, it would have been an enormous amount of email to explain this 
whole problem.
The way this interoperability works for mips16/mips32 is from gcc and 
there is no documentation on it; you have to read the code of the 
compiler and old emails from the gcc list  to understand it.

One of the things I have assigned to myself as a bug is to finally 
document this whole
design of the mips16/32 floating point interoperability.

I do very often discuss many of the design issues I'm dealing with and 
elicit help and opinions from the LLVM list (and have received much very 
helpful advice that has simplified my work
greatly).

Unfortunately, this issue of assembly code is a minor detail at the end 
of this and we never
considered that to be important or I would have brought it up.

On the other hand, I'm far from an LLVM expert and I have to do things 
using the tools
and knowledge I have available to me and this path using IR was very 
clear to me and I'm very
happy how the design and coding came out. Maybe when you see the patch 
you can suggest
another way to do this piece of emitting the asm code. I can't guarantee 
that my management will allow me to spend more time redoing things that 
already work.

All of this code is isolated in a single module IR pass.

So it will be very easy to replace it with some other pass in the future 
if someone has the energy to redo it or if other features become 
available that make it easier. The pass as it stands also documents well 
the issues involved and how they can be simply addressed.

They have been adding features and optimizations to mips16 gcc for 10 
years and lots of people have worked on it and I'm the only one working 
on it for LLVM. I did none of this
work on gcc for mips16 and only started seriously working on this port 
at the end of
last May. This mips16/mips32 floating point interoperability is just one 
of many things I have
to implement.

So i have to just move ahead.

Anyone with energy and interest is welcome to help.

Reed



> 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