[PATCH] D14707: add fast-math-flags to 'call' instructions (PR21290)

Sanjay Patel via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 17 09:51:52 PST 2015


On Tue, Nov 17, 2015 at 10:24 AM, Tim Northover <t.p.northover at gmail.com>
wrote:

> On 17 November 2015 at 09:04, Sanjay Patel <spatel at rotateright.com> wrote:
> > Thanks for looking at this patch. I didn't consider new function
> attributes
> > for this, and I don't understand the trade-offs. Can you explain why
> > function attributes might be lighter?
>
> I only meant the syntactic alterations. The handling changes are
> likely to be similar either way, but you wouldn't need to change any
> part of bitcode parsing or its format. The following is already
> accepted by unmodified LLVM, for example:
>
>     declare void @foo()
>     define void @bar() {
>       call void @foo() "wibble"
>       ret void
>     }
>
> > If it is lighter to use attributes, can we make the argument that all FMF
> > should be done that way? Ie, nuke the existing FMF?
>
> I don't think instructions (other than calls) have attributes at the
> moment; they're very much a function-based concept. I can see the
> appeal of a unified system though; I suppose it comes down to whether
> we want unified tags on function calls or unified fast-math tags more.
>

Ah, I get it now. Instead of FMF after "call" and before "float", we can do:
call float @sqrtf(float %x) nnan ninf readnone nounwind

But then yes, calls' FMF looks a bit different than the other instructions.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151117/60479e73/attachment.html>


More information about the llvm-commits mailing list