[llvm-commits] Patch: Fast-math flags for intrinsics

[Chandler Carruth]

On Tue, Dec 18, 2012 at 5:42 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Dec 18, 2012, at 2:07 PM, Michael Ilseman <milseman at apple.com> wrote:
>
> > Attached are patches for fast-math support for IntrinsicInst. This
> includes bitcode changes to separate out IntrinsicInsts from CallInsts.
> >
> > First patch:
> >
> > Helper functions and minor refactoring.
> >
> > Added explicit const to unchanged record reference for API clarity.
> Added helper functions for the reading and setting of fast-math flags and
> call arguments. Cleaned up the include lines.
> >
> >
> > Second Patch:
> >
> > Intrinsic support for fast-math flags.
> >
> > Previously, IntrinsicInsts were handled as CallInsts. However,
> intrinsics can now have fast-math flags, and thus merit a separate bitcode
> encoding. This change adds FUNC_CODE_INST_INTRINSIC for intrinsic calls,
> separates them out from general calls, and adds encoding and decoding of
> fast-math flags. Backwards compatibility is retained. Adds parsing
> fast-math flags for IntrinsicInsts, and more tests.
>
> I'm pretty strongly against this.  A major feature of intrinsics (as
> opposed to well-known libcalls) is that they can have immediate operands to
> capture additional information.  For example, the known alignment of a
> memcpy is captured as an argument to intrinsic, even though the libc memcpy
> call doesn't have it.
>
> Similarly, it doesn't make sense to make the concept of "intrinsics in
> general" more complicated to handle fast math.  "Fast math intrinsics"
> should either be modeled by adding new immediate operands to llvm.sin (and
> friends) or by using per-instruction metadata on these intrinsic calls.


Yes. Both of these options make perfect sense to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121218/b77a3bf6/attachment.html>