[LLVMdev] ARM MC .s status?

[Renato Golin]

On 15 September 2010 15:52, Rafael Espindola <espindola at google.com> wrote:
> There is one for x86/x86-64 on the works. It has some limitations, but can
> produce working binaries for small programs like screen.

Hi Rafael,

This is good, at least we don't start from scratch and we can
cooperate with the other team to make sure the generic ELF
infrastructure remains generic.


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

My previous relocation patch decides which relocation to use based on
the section and expression type, but that might not be the best way to
go for it. I think we should try to get it *before* ELF or ASM, so we
only implement that once.

If we have to extend some generic relocation mechanism, even better,
but that has to be generic in the MC level, not ASM/ELF streamers,
IMHO.


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

The EABI attributes that define the compilation options / platform
definitions, to propagate them to assembler and linker in case you use
multiple steps to compile.

Normally, just by choosing Cortex-A8, you can assume NEON exists, but
not all A8 have NEON and you can end up wrongly generating vector
instructions to a platform that doesn't support it. The "solution" is
to compile all at one step, but that's also far from ideal.

In effect, only having "armv7a-eabi-none" as a triple is very limiting
in ARM world. And since our designs can be extended in an very large
number of combinations, adding it to the triple is not the way to
go...

The attributes can be generically used by other platforms, that, once
it's required, it can help on generating correct code (sometimes
better code), like in the case of unions discussed earlier.

If front-ends ignore it, they can still generate code and rely on the
back-end knowing what they meant, but front-ends that want to
communicate to back-ends via IR/ASM/ELF can do so, especially for JIT
and multi-step compilations.

CodeSourcery's GCC already generates and understands that (to a
point), so there is no compatibility issues.

-- 
cheers,
--renato