[LLVMdev] ARM MC .s status?

[Renato Golin]

Hi Jason, Jim, Rafael,

We had plans to work on ARM MC (asm and elf), good to see there is an
interest, and we'd be glad to help.

The ARM part of MC is almost empty, so there's a lot of work in there,
probably even before writing the assembly/ELF writers. Also, AFAIK,
there is no ELF writer for MC, so wouldn't be good to write one
specific for the ARM platform, but keep things generic as much as
possible.

As I got it, MC is generic and the file writers only get the
instructions and sections and "print" them to file. Does it mean MC
already have all the section, relocation, attributes, properties that
both ASM and ELF have? If that's so, even though they're separate
projects (as Jason pointed out), a higher degree of communication will
be required to synchronize the MC part.

Also, we want to make sure that the generated ASM/ELF is not only GNU
compatible, but ARM ABI too (if the user require, in the target
triple). We have done some changes to the ISelLowering to conform to
EABI, a patch is on its way. Is it correct to assume that, if the user
chooses a triple with "eabi-none", we can generate ARM EABI (including
RT-ABI intrinsics) code?


> 1. MC-ized Assembly Printer

Would be good to make it generic enough, so we could (hypothetically)
add ARM assembly as a choice. But that could come as a great weight in
the first draft, so I won't be so sad if we can't get it straight
away. ;)

Irrespective of the asm syntax, we need better support for build
attributes, relocation information, stack unwinding, exception tables,
etc. That alone should prove a good challenge.

In the meantime, we have worked on support for some of these things
(build attr, reloc.) for the old writer. I'm preparing some of them as
patches and will send soon.


> 2. Object File Emission

That will also need support for features mentioned above, and also in
the disassembler.

GCC ignores most of the build attributes and "guess" everything else
from cpu, fpu and the instructions used. This is far from ideal and we
shouldn't follow the same route. If we need to guess anything, lets do
it in MC, so when you print assembly, the user can later edit if they
so want to (or pass the correct cmd-line options to create them right
in the first place). The disassembler should also understand that and
*always* give preference to user attributes.

Because ASM and ELF writers will use MC, we need explicit relocation
information in MC, so the writer can print it correctly to the file. I
saw that the Dwarf printer has this working, but the old ARM AsmWriter
doesn't (I sent a patch for this a while ago). Maybe we can join them
all in MC this time.


> 3. JIT. Same basic approach as (1) to replace the current object code emitter with an MC based one.

We're not overly concerned about JIT at the moment, but it's good to
keep in mind that we also have that route.

I would as far as to suggest to create a third data section in the IR,
after "target-data-layout" and "target-triple", maybe called
"target-info" or "target-options". It could be a target dependent
string, but would be best if it was shared among architectures, so you
could run IR generated to ARM in an 32bit x86, for instance.

We could also pass target specific features (such as build
attributes), how to handle unions and ByVal parameters, and maybe some
optimization assumptions when generating IR.

That would allow the codegen phase to detect not only what was
generated, but why, and make the appropriate changes if the execution
target does not conform to the intended target's specifications. That
is very liberating for JIT environments, but I do realise this is
extremely complex.

I'd be happy to have just the build attributes on it for now, though. ;)

cheers,
--renato