[LLVMdev] ARM MC .s status?

[Rafael Espindola]

> 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.

There is one for x86/x86-64 on the works. It has some limitations, but can
produce working binaries for small programs like screen.

> 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.

I am just starting with MC, but as I understand it, the interface to the
streamer is basically one call per assembly directive. Things like
relocation have to be recorded by the streamer implementation. The
ELF one has to be extended to create the ARM specific relocations.

> 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?

That is almost all decided before getting to the MC streamer I think. So there
might be some work for supporting other ABIs, but I suspect most of it would
be in the IL to DAG conversion.

>
>> 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.

Tables in general are produced one level before MC I think.

> 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. ;)

Can you give an example of what attributes you have in mind?

> cheers,
> --renato

Cheers,
-- 
Rafael Ávila de Espíndola