llvm dev - Nov 2010 - [LLVMdev] Build Attributes Proposal

Hi Renato,
> On 13 November 2010 15:12, Duncan Sands<baldrick at free.fr>  wrote:
>> I agree that it's limited.  As for MC, it will need to handle these
strings
>> anyway since this is an existing LLVM feature (coming from gcc
originally)
>> that needs to be supported.
>
> Do you mean that LLVM-GCC generates build attributes as asm strings in IR?
no, I mean that gcc supports file level ASM, which is why llvm-gcc and LLVM
support it too, and which presumably means that MC will have to support it
one day.
>> Because magic globals need magic treatment, i.e. special logic in the
code
>> generators etc.  Why add all this new stuff if an existing feature will
do?
>
> Build attributes are not asm specific, and implementing them in an asm
> specific keyword seems kludge to me. Not to mention that you lock the
> IR in a ARM-GNU-ASM specific mode, which is a dead-end. Also, passing
> ".build_attribute" strings in IR if you're producing ELF
doesn't make
> sense, IMO.
It is hard for me to comment because I don't know anything about these
attributes.  However, presumably they need to end up in the .s file.
I'm pointing out that you can put anything you like into the assembler
via module level asm.  I'm not sure what you mean by "build attributes
are not asm specific".  I never suggested they were!  The so-called asm
is just a directive saying: place this string as-is in the final assembler.
I'm also not sure what ELF has to do with anything.
> In a global array, the indexes are represented directly, only leaving
> the associated string if additional information is necessary (like CPU
> name, which is already a string).
Since I don't know anything about these attributes, talk of indexes and
so forth goes straight over my head.

All I'm saying is that if you want a series of strings to end up in the
.s file, this can be done using an existing LLVM feature.

Ciao,

Duncan.

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.

cheers,
--renato

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
>