[llvm-dev] EuroLLVM Numerics issues

Kaylor, Andrew via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 2 18:16:56 PDT 2019

Hi Michael,

Thanks for raising this topic. I am very interested, but unfortunately I won't be at EuroLLVM. Here are some things on my mind, roughly in order of how much time I've spent thinking about them:

Constrained intrinsics
This has been dragging on for a really long time now. I'm at least partially responsible for that as I got it started but haven't had the time recently to respond quickly to the review request of other contributors. (My sincere apologies to those affected. I hope it is making its way back toward the top of my priority list.) I'd like to come up with a plan to get the initial implementation finished.

As Cameron mentioned there is a lot of work left to be done in terms of transferring the strict FP controls from IR to MIR across ISel. The current implementation basically punts and hopes for the best at that point. Ulrich Weigand submitted a patch, but it has been languishing in review for quite a long time. Honestly, I don't know the ISel code well enough to evaluate his approach.

Besides the backend transition problems there is a lot of work to be done to teach existing optimizations to handle the constrained intrinsics. Also, something needs to be done in the front end to generate the intrinsics. A patch has been submitted to do something about this in IRBuilder, but I don't believe anything has been done in the front end.

Precision modes
Right now, we more-or-less support FLT_EVAL_METHOD=-1 when fast math is enabled and FLT_EVAL_METHOD=0 when we're in precise mode. If we're generating code for pre-SSE 32-bit Intel architecture we use FLT_EVAL_METHOD=2 instead. Other architectures may have similar variations. All of this is fine as default behavior, but I'd be interested in having the ability to explicitly specify FLT_EVAL_METHOD=1 and FLT_EVAL_METHOD=2. I believe this would primarily involve work in the front end(s).

Related to the topic of finer grained control over FP optimizations, there are a slew of pragmas that would be nice to have. The most obvious one is FENV_ACCESS, which we've said is what the constrained intrinsics are driving toward. More recent standards proposals have added pragmas to locally declare rounding modes. Then there are a bunch of non-standard pragmas on my list that the Intel compiler supports to control FP optimizations. An example is float_control, which I believe we added for MSVC compatibility but also find useful on other platforms. I'd love to see support for things like this in clang.

Masked vector FP operations
We've resisted adding explicitly predicated operations other than load and store in the past, but I think for vector FP operations we're going to need this in order to maintain strict FP semantics.

SVML and other vector libraries
There is support in LLVM for generating calls to Intel's Short Vector Math Library when code is vectorized. This probably needs to be more aware of various FP modes. I expect we'd like to support other libraries with similar needs.

Complex types
There, I said it.

Accuracy controls
We have a fast math flag that lets us substitute approximations for some math library functions. It would be nice to have a mechanism to control the accuracy of the approximations.

Per function controls
Similarly, it would be nice to explicitly list which math library functions could be replaced.

I'd also like to suggest the formation of a floating point working group to try to get more organized about driving some of these things (particularly the constrained intrinsics) toward completion.


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Michael Berg via llvm-dev
Sent: Friday, March 29, 2019 10:05 AM
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] EuroLLVM Numerics issues

All:  There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization).

Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog if you like for reference material:


p.s. (restarting this thread here).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190403/28f9f105/attachment.html>

More information about the llvm-dev mailing list