questions about ARM EABI attributes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

questions about ARM EABI attributes

Akira Hatanaka
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" }




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: questions about ARM EABI attributes

Renato Golin-2
On 19 December 2014 at 01:37, Akira Hatanaka <[hidden email]> 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: questions about ARM EABI attributes

chalieturner
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 <[hidden email]> wrote:

> On 19 December 2014 at 01:37, Akira Hatanaka <[hidden email]> 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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: questions about ARM EABI attributes

Akira Hatanaka
Thanks Renato and Charlie. This is very helpful.

On Fri, Dec 19, 2014 at 5:25 AM, Charlie Turner <[hidden email]> wrote:
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.


Since the linker already has the logic to merge the attributes or resolve any incompatibilities between them, I was hoping I would be able to give attributes to each function instead of emitting once at the start of the file. Unfortunately, that's not the case so we have to replicate that logic and compute the merged values based on the attributes of all the functions in the module.
 
> 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.


Yes, it seems that the the most strict requirement should be used here, but probably that should be discussed later along with other ARM build attributes that depend on attributes that can change on a per-function basis.
 
Kind regards,
Charlie.

On 19 December 2014 at 10:44, Renato Golin <[hidden email]> wrote:
> On 19 December 2014 at 01:37, Akira Hatanaka <[hidden email]> 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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev