[LLVMdev] Build Attributes Proposal

[Renato Golin]

2010/11/17 Rafael Espíndola <rafael.espindola at gmail.com>:
> So, you mentioned that there should be no attributes that were not
> requested by the users, right? If that is so, can't you produce the
> asm in clang or you FE and have llvm never introduce new ones? LLVM
> itself doesn't use the attributes, so it doesn't need to interpret
> them.

This comment is a bit misleading...

First, The user chooses the cpu, fpu, calling convention,
floating-point optimizations, instruction sets, etc. Most of it is
encoded in the target triple (ex: thumbv6m), others in command-line
options (-mcpu, -mfpu, etc). Based on that fact, yes, the build
attributes are always requested by the user, but that's not the whole
story. The user can request incompatible attributes (like thumbv4), so
the compiler as to warn or stop. Some attributes in one object can be
incompatible with another object, and it's up to the linker to
recognized that, merge if possible or bail out otherwise. There is
room for guessing, but the idea of the build attributes are precisely
to reduce that guessing game as much as possible to force errors in
compile time rather than run time.

Second, as you know, build attributes are not exclusively assembly
tags, they have to be printed to ELF as well, and the ARM ELF back-end
will have to get that information somewhere. The best part of this
information will come from SubTarget, as we discussed before, but some
restrictions must come from somewhere else. So the LLVM back-end must
interpret them when they come, and parsing asm is not the way I'd do
it.

However, depending on how you compile using LLVM, you might not need
it in the IR. The reason is that the command-line options can be
passed straight through ASM/ELF if you compile using some driver
(clang, llvm-gcc). But that won't work if you compile to BC, than
compile to ASM/ELF later. My personal opinion is that, independent on
how you compile your file, the result should be the same. So, having
build attributes in the IR is the only choice.

One could argue that it's not necessary, the docs could cover that
easily and we wouldn't have to add an extra complexity to the IR.
Based on how Clang parameters for target triple work today (-ccc
against -cc1 ...), I guess that decision was taken before, so that
wouldn't be a first. But that's obviously not my call.

I could go over the build attributes list to name a few important
ones, but there're two that comes to my mind: ARM/Thumb
interoperability and FP optimization level (IEEE, fast), both
important for choosing the right libraries/calls at link time. I don't
believe there is any other way of representing them in IR today... But
I could be wrong, obviously...

best,
--renato