[LLVMdev] 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 <charlesturner7c5 at gmail.com>
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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141222/9ab1cc51/attachment.html>