<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 17, 2015 at 10:24 AM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 17 November 2015 at 09:04, Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>> wrote:<br>
> Thanks for looking at this patch. I didn't consider new function attributes<br>
> for this, and I don't understand the trade-offs. Can you explain why<br>
> function attributes might be lighter?<br>
<br>
</span>I only meant the syntactic alterations. The handling changes are<br>
likely to be similar either way, but you wouldn't need to change any<br>
part of bitcode parsing or its format. The following is already<br>
accepted by unmodified LLVM, for example:<br>
<br>
    declare void @foo()<br>
    define void @bar() {<br>
      call void @foo() "wibble"<br>
      ret void<br>
<span>    }<br>
<br>
> If it is lighter to use attributes, can we make the argument that all FMF<br>
> should be done that way? Ie, nuke the existing FMF?<br>
<br>
</span>I don't think instructions (other than calls) have attributes at the<br>
moment; they're very much a function-based concept. I can see the<br>
appeal of a unified system though; I suppose it comes down to whether<br>
we want unified tags on function calls or unified fast-math tags more.<br></blockquote><div><br></div><div>Ah, I get it now. Instead of FMF after "call" and before "float", we can do:<br></div><div>call float @sqrtf(float %x) nnan ninf readnone nounwind<br></div><div><br></div><div>But then yes, calls' FMF looks a bit different than the other instructions.<br><br></div><div>I don't have a preference either way. If anyone likes the attribute way better, please let me know, and I will redo this patch.<br></div><div><br> </div></div></div></div>