[PATCH] D41338: [CodeGen] lower math intrinsics to finite version of libcalls when possible (PR35672)

Andy Kaylor via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 3 18:09:52 PST 2018

andrew.w.kaylor added a comment.

In https://reviews.llvm.org/D41338#964520, @spatel wrote:

> In https://reviews.llvm.org/D41338#960487, @hfinkel wrote:
> > In https://reviews.llvm.org/D41338#958611, @efriedma wrote:
> >
> > > > Does this make sense for ISD::STRICT_FEXP (the strict version of the node)?
> > >
> > > I would guess strict and fast math don't really mix...
> >
> >
> > I agree.
> Sorry for the delay. Let me address this comment first. I would agree too, but I was informed that there's a clang customer in the gaming world that wants to compile with -ffast-math **and** enable div-by-zero FP exceptions as a way to sanitize their data (at least in development builds).
> I assume that we're still a long way from realizing this dream (optimized FP + some subset of FP exceptions enabled) in LLVM, but if there's no correctness issue with allowing this transform, then I think we should treat these nodes the same in this patch.

I feel like there are still a lot of things that need to be figured out with regard to StrictFP and ISel. What's there now is just kind of a "get something working" solution, and I think it will need to be beefed up later.

Regarding the original question about mixing fast math and strict FP, I think what the gaming customer is asking for sounds reasonable. The strict FP intrinsics handle two things that are at least potentially separate: value safety and exception behavior.  The fast math flags mostly affect value safety, but there are some transformation that could change exception behavior. That will have to be thought through when individual transformations are taught to recognize the constrained intrinsics. More generally, it's certainly reasonable to indicate via the intrinsics that you want to preserve exception behavior but that you don't care about rounding mode. How the user would get the front end to do that is another question, because I think it will have to be something other than using the FENV_ACCESS pragma and -ffast-math together (which I would hope would trigger a warning saying that one of them was going to be ignored).


More information about the llvm-commits mailing list