[LLVMdev] ARM MC .s status?

[Jason Kim]

On Wed, Sep 15, 2010 at 2:27 AM, Renato Golin <renato.golin at arm.com> wrote:
> 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.

Yeah, not to mention, the Apple folks are probably not interested much
on ELF as mach.o, so there's probably even more genericity to be
considered.

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