questions about ARM EABI attributes

ARM backend emits different eabi build attributes based on the ISA variant the target supports or whether certain fast-math options are passed on the command line. For example, these are the attributes that have different values depending on whether -ffast-math is passed to clang:

$ clang -target armv7-linux-gnueabi -ffast-math (with -ffast-math)

.eabi_attribute 20, 2 @ Tag_ABI_FP_denormal

.eabi_attribute 23, 1 @ Tag_ABI_FP_number_model

$ clang -target armv7-linux-gnueabi (without -ffast-math)

.eabi_attribute 20, 1 @ Tag_ABI_FP_denormal
.eabi_attribute 21, 1 @ Tag_ABI_FP_exceptions
.eabi_attribute 23, 3 @ Tag_ABI_FP_number_model

Suppose there are two functions in a module which have different sets of function attributes. One function has attributes for “-ffast-math” (foo1) and the other (foo0) has attributes for “-fno-fast-math”. In that case, which set of eabi attributes should ARMAsmPrinter::emitAttributes emit? ARMAsmPrinter::emitAttributes is called once at the start of a file (not once per every function), so I assume it has to merge those attributes which have different values or reject the IR if it discovers incompatibilities.

define double @foo0(double %a) #0 {
entry:
%add = fadd double %a, 1.000000e+00
ret double %add
}

define double @foo1(double %a) #1 {
entry:
%add = fadd fast double %a, 2.000000e+00
ret double %add
}

attributes #0 = { nounwind readnone “less-precise-fpmad”=“false” “no-frame-pointer-elim”=“true” “no-frame-pointer-elim-non-leaf” “no-infs-fp-math”=“false” “no-nans-fp-math”=“false” “stack-protector-buffer-size”=“8” “unsafe-fp-math”=“false” “use-soft-float”=“false” }

attributes #1 = { nounwind readnone “less-precise-fpmad”=“false” “no-frame-pointer-elim”=“true” “no-frame-pointer-elim-non-leaf” “no-infs-fp-math”=“true” “no-nans-fp-math”=“true” “stack-protector-buffer-size”=“8” “unsafe-fp-math”=“true” “use-soft-float”=“false” }

Hi Akira,

Build attributes were not created to describe everything inside the
file, but to help you identify what support you need (or don't want)
in order to link with the most appropriate libraries, if you have more
than one.

In this case, I'd say the best course of action would be to set the
attribute to the least restrictive one, which in this case is to
accept fast-math.

cheers,
--renato

Hi Akira!

Akira said,
Suppose there are two functions in a module which have different sets of function attributes.
One function has attributes for "-ffast-math" (foo1) and the other (foo0) has attributes for "-fno-fast-math".
In that case, which set of eabi attributes should ARMAsmPrinter::emitAttributes emit?

That's an interesting question and a use-case I hadn't considered
whilst working on the build-attribute support recently.

An ABI-compliant linker has a set of rules for combing different
attribute values across objects which are documented in section 2.1.5
of the addenda to ARM ABI. If you wanted to combine attribute values
across attribute sets within a module, I think you would have to
implement the same set of rules in the attribute emitter. I'm sorry to
report that no such functionality exists AFAICT.

Renato said,
Build attributes were not created to describe everything inside the
file, but to help you identify what support you need (or don't want) in order to link with the most appropriate libraries, if you have more than one.

There is a notion of attribute scopes, where build attributes could be
given to individual entities defined in an object, specifically to
function or data objects identified by an ELF symbol definition (2.1.3
of the ABI addenda), but this use of build attributes is deprecated in
version 2.09 of the ABI (to which I'm trying to get LLVM to conform),
where producers are discouraged from generating them, and consumers
may ignore them.

Renato said,
In this case, I'd say the best course of action would be to set the attribute to the least restrictive one, which in this case is to accept fast-math.

My impression would be that you must emit attributes suitable for
-no-fast-maths, the most strict requirement in this example, and
assume a IEEE-conformant soft-math library will be linked for foo0's
use.

Kind regards,
Charlie.

Thanks Renato and Charlie. This is very helpful.