[llvm-dev] EuroLLVM Numerics issues

Wed Apr 3 07:04:28 PDT 2019

>====================

>Complex types

>====================

>There, I said it.

Oh hell yes!

On Tue, Apr 2, 2019 at 9:17 PM Kaylor, Andrew via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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).
>
>
>
> ====================
>
> pragmas
>
> ====================
>
> 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.
>
>
>
> -Andy
>
>
>
>
>
> *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:
>
> http://blog.llvm.org/2019/03/llvm-numerics-blog.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2019_03_llvm-2Dnumerics-2Dblog.html&d=DwMFAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=lIxcsC2UyeGJi5Hn2huNzHXpqgf5OzZOf92RyNrXmJs&s=wCMWl0WYVSS4STsD_VcW77mg3aHBvei1BQTGnTgl9Rw&e=>
>
>
>
> p.s. (restarting this thread here).
>
> Regards,
> Michael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=lIxcsC2UyeGJi5Hn2huNzHXpqgf5OzZOf92RyNrXmJs&s=eT5NAwfcMF1MZh1ZXX0wwF3AMD2hFNllRAJS4Dd2wVU&e=
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190403/203a7561/attachment.html>