[LLVMdev] Build Attributes Proposal

[Jason Kim]

Hi Renato, everyone

On Sat, Nov 13, 2010 at 2:17 PM, Renato Golin <renato.golin at arm.com> wrote:
> On 13 November 2010 21:15, Duncan Sands <baldrick at free.fr> wrote:
>> Since I don't know anything about these attributes, talk of indexes and
>> so forth goes straight over my head.
>
> Hi Duncan,
>
> I assumed you knew what build attributes were in the first place, my mistake.
>
> For a full explanation of what they are, see ARM ABI Addenda, section
> 2.1 (PDF). (Google's first hit for "arm abi addenda").
>
> Simply put, build attributes express the user explicit intentions when
> compiling code, so the linker can take better decisions when linking
> the objects. These attributes apply normally to whole units, but could
> apply to sections or even symbols, to express the compatibility or
> preference towards specific components. With build attributes, it's
> easier to pass information between tool chains, as some choices might
> be obvious within the tool chain, but different across.
>
> For example, the LLVM tool chain assumes that every Cortex-A8 has
> NEON, while the ARM tool chain does not. So, if you compile a file
> with Clang for Cortex-A8 and link with LLVM linker (or LD), everything
> works fine, because that assumption is in every step of the tool
> chain. However, if you try to link with armlink, it won't work, as the
> NEON attribute (Tag_Advanced_SIMD_arch) will not be there, and when it
> finds vector instructions, it'll bail out.
>
> Another example I quote from the ABI:
>
> "The compiler might choose to use only the Thumb ISA in a specific
> build of a source file.
> Nonetheless, the relocatable file should be tagged as having been
> permitted to use the ARM ISA so that a linker can later link it with
> ARM-state library code and generate ARM-state intra-call veneers if
> that gives benefit to the executable file.
> On the other hand, if the user intends code to be executed by both
> ARM7TDMI and Cortex-M3, the compiler must be constrained to generate
> only Thumb v1 instructions and the relocatable file should be tagged
> as not permitted to use the ARM ISA."
>
> So, as you can see, this gives the user and library writers freedom to
> optimize and specialize their code to perfection. In a highly
> segmented market such as ARM's, where every manufacturer has its own
> ways to connect the components or build SoCs, this is the only way to
> completely customize the tool chain to a completely customized
> architecture.
>
> Also, it's not something restricted to assembly only, but it's also
> stored in ELF files (global, sections, symbols). This are also well
> documented, long-lasting definitions that all ARM ABI compatible
> compilers should honour when producing and consuming object files.
> Specific manufacturer can also come up with a new set of attributes
> that are specific to their own architecture, and as long as they don't
> collide with the public definitions, other manufacturers are free to
> ignore.

I think there are several common use cases for these attributes -
1. to mark what ISA a function is compiled for: (i.e. is it a
thumb16/thumb32/ARM?)
2. to constrain the generated code to use specific co-processors.

At least for case 2, the ARMTargetMachine/ARMSubtarget contains a
distinct set of flags which should be output in the file scope section
of the attributes
For case 1, I don't know how common it is for the same executable to
cross thumb boundaries - (given that16bit thumb has limits on register
usage etc..) but I suppose its possible.

For now, I agree with Renato that using the Module-Level Inline
Assembly is probably not the right way to go - for example, some of
the messyness of .cpu asm statement mapping to many FileScope
attributes is the primary cause of the (likely) not-clean looking code
that needs to go into the current .ARM.attributes emitter for ELF.

What I would like to find out is the current set of supported ASM
attributes by the current AEABI compiler. Once *that* info is
available, we can go about sensibly factoring the required behavior in
LLVM -

Just my 2c.

-jason

>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>