[LLVMdev] Build Attributes Proposal

[Renato Golin]

On 16 November 2010 02:01, Jason Kim <jasonwkim at google.com> wrote:
> 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

Yes, getting the default behaviour from SubTarget is the easy part
(mostly done, now, I believe).


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

It is possible and often used.


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

I can't make out which "AEABI compiler" you're talking about, but yes,
I agree with your approach.

There are essentially two "types" of attributes:

 1. Hardware compatibility: arm/thumb, softfp/vfp/neon, fp precision,
registers to use, etc. These are more likely grabbed from the
SubTarget and changed according to the command-line options. We can
get away for the moment just by using the target descriptions and
automatically filling build attributes (without changing the IR).
Specific targets, like NVidia's Tegra2 (Cortex-A8 without NEON) will
break, though.

 2. Binary compatibility: procedure call standard to use (apcs, aapcs,
vfp), size of wchar_t and enums. It's not crystal clear what
determines all of these parameters, so the user aspect (cmd-line
options) is more important in this case, and they should be honoured.
This is a much more complicated issue, but the IR already has some
information (like function attributes) that help in that matter.

So, for the moment, without changing the IR would get us far enough.
But some of these attributes will have to be recorded, eventually, and
that was the motivation of this preliminary discussion on how to
represent them in IR.

The list of build attributes supported by GCC must be hidden in its
own source code somewhere. The options that will, eventually (I hope),
set them are:

http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

As you see there isn't a 1-to-1 relationship between command-line
options, target description and build attributes, and linkers are free
to interpret them (at least the binary compatibility ones) as they see
fit.

cheers,
--renato

PS: The size of wchar_t and enums are also in line with the size and
alignment for unions and bitfields we were talking about earlier, thus
why I thought that there could be a global attribute (@llvm.attribute)
rather than just an ARM specific one (@llvm.arm.attribute).