[LLVMdev] Build Attributes Proposal

[Renato Golin]

Hi Duncan,

I'm not sure you're arguing against having global build attributes
(instead of just specific ones), or against the whole idea of having
build attributes.

I'll assume the former, as I take it that having support for ARM build
attributes in LLVM is important (for compatibility, at least).


On 12 November 2010 16:20, Duncan Sands <baldrick at free.fr> wrote:
> * optimization level: if you want the linker to optimize at -O3, I think
> you should just pass -O3 to the linker.  I don't see why the fact that
> the original files were optimized at -O3, -O0, -O0 and -O3 (for example)
> is relevant to link time optimization.
>
> * specific optimizations: likewise.
>
> * floating point compatibility: not sure what you mean by this.

I don't have any specific optimization in mind, but some ARM build
attributes refer to the way optimizations and floating-point were
assumed when compiling.

If the user required IEEE 754 precision when compiling, you should
honour that, possibly using libraries that guarantee you won't diverge
from the standard.

Please read the Addenda for more information:

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045c/index.html
(chapter 2.3.7)

There could be similar assumption in Intel or PowerPC, they're not
exclusively on ARM, so having them on a global attribute list (that
can easily be ignored by any target), could help.


> * use of vector instructions: if you want the linker to codegen for SSE3,
> then pass -msse3 to the linker.

It's not always that simple. In some benchmarks or build systems you
can't easily fiddle with the linker parameters and the compilation is
done in multiple, separated steps, so it's also not easy to propagate
the user options as they don't share the same driver.

Also, a vectorized attribute would tell if you have to link with
vectorized libraries or normal ones, and if you have multiple styles
of vector code (mmx, sse, etc) you could choose which one, even if the
user haven't asked for a specific one.

AFAIK, GCC assumes that, if you have vectorized code, you want
vectorized libraries and vice-versa. But that's very simplistic. It
may occur that your code was so small that couldn't be vectorized, but
you still want vectorized libraries or vice-versa. While you can do
that by passing arguments to the linker, you may be in a situation
where you cannot pass arguments to the linker in the first place, or
you can't re-compile part of your program (no source?) and want to
enforce a different set of rules to the rest of the system.


> * use of exceptions: if a file is compiled with -fno-exceptions then
> all functions have the nounwind attribute and contain no invokes.
> This is all that is needed to automatically have the code generators
> not generate unwind info for them, so no special module level attribute
> is needed, everything is there already.

Well, not generating unwind information for your functions doesn't
mean you can't have them in the libraries. If your code is not
expecting exceptions to be thrown, and you have libraries that don't
throw them, you can use the appropriate libraries for your code.

Also, if you have nounwind in one source but not in the other, the
compiler can't predict all the interoperability problems that will
come from that, if you compile all of them together. With such a build
attribute, the compiler might print a warning (or even an error) for
cases where there could be potential problems when intermixing
different assumptions.


See, I'm not enforcing a standard behaviour on the global
@llvm.attributes. I don't even need it, to be honest, but I didn't
want to propose such a system without accounting for the general case.
>From my point of view, it's important to have ARM build attributes in
the front-end all the way to the back-end. If other platforms can use
the same encoding, better, if not, I don't mind.

Just having @llvm.arm.attributes would be fine for me...

cheers,
--renato