llvm dev - Dec 2014 - [LLVMdev] 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" }
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/3fa06a5b/attachment.html>

On 19 December 2014 at 01:37, Akira Hatanaka <ahatanak at gmail.com>
wrote:
> 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.
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.

On 19 December 2014 at 10:44, Renato Golin <renato.golin at linaro.org>
wrote:
> On 19 December 2014 at 01:37, Akira Hatanaka <ahatanak at gmail.com>
wrote:
>> 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.
>
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev