<div dir="ltr">Thanks Renato and Charlie. This is very helpful.<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 19, 2014 at 5:25 AM, Charlie Turner <span dir="ltr"><<a href="mailto:charlesturner7c5@gmail.com" target="_blank">charlesturner7c5@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Akira!<br>
<br>
> Akira said,<br>
<span>> Suppose there are two functions in a module which have different sets of function attributes.<br>
> One function has attributes for "-ffast-math" (foo1) and the other (foo0) has attributes for "-fno-fast-math".<br>
> In that case, which set of eabi attributes should ARMAsmPrinter::emitAttributes emit?<br>
<br>
</span><span>That's an interesting question and a use-case I hadn't considered<br>
whilst working on the build-attribute support recently.<br>
<br>
An ABI-compliant linker has a set of rules for combing different<br>
attribute values across objects which are documented in section 2.1.5<br>
of the addenda to ARM ABI. If you wanted to combine attribute values<br>
across attribute sets within a module, I think you would have to<br>
implement the same set of rules in the attribute emitter. I'm sorry to<br>
report that no such functionality exists AFAICT.<br>
<br>
> Renato said,<br>
</span><span>> Build attributes were not created to describe everything inside the<br>
> 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.<br>
<br>
</span><span>There is a notion of attribute scopes, where build attributes could be<br>
given to individual entities defined in an object, specifically to<br>
function or data objects identified by an ELF symbol definition (2.1.3<br>
of the ABI addenda), but this use of build attributes is deprecated in<br>
version 2.09 of the ABI (to which I'm trying to get LLVM to conform),<br>
where producers are discouraged from generating them, and consumers<br>
may ignore them.<br>
<br></span></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
> Renato said,<br>
</span><span>> 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.<br>
<br>
</span><span>My impression would be that you must emit attributes suitable for<br>
-no-fast-maths, the most strict requirement in this example, and<br>
assume a IEEE-conformant soft-math library will be linked for foo0's<br>
use.<br>
<br></span></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
Kind regards,<br>
Charlie.<br>
<br>
</span><div><div>On 19 December 2014 at 10:44, Renato Golin <<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>> wrote:<br>
> On 19 December 2014 at 01:37, Akira Hatanaka <<a href="mailto:ahatanak@gmail.com" target="_blank">ahatanak@gmail.com</a>> wrote:<br>
>> Suppose there are two functions in a module which have different sets of<br>
>> function attributes. One function has attributes for "-ffast-math" (foo1)<br>
>> and the other (foo0) has attributes for "-fno-fast-math". In that case,<br>
>> which set of eabi attributes should ARMAsmPrinter::emitAttributes emit?<br>
>> ARMAsmPrinter::emitAttributes is called once at the start of a file (not<br>
>> once per every function), so I assume it has to merge those attributes which<br>
>> have different values or reject the IR if it discovers incompatibilities.<br>
><br>
> Hi Akira,<br>
><br>
> Build attributes were not created to describe everything inside the<br>
> file, but to help you identify what support you need (or don't want)<br>
> in order to link with the most appropriate libraries, if you have more<br>
> than one.<br>
><br>
> In this case, I'd say the best course of action would be to set the<br>
> attribute to the least restrictive one, which in this case is to<br>
> accept fast-math.<br>
><br>
> cheers,<br>
> --renato<br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div></div>