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 <http://blog.llvm.org/2019/03/llvm-numerics-blog.html> p.s. (restarting this thread here). Regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190329/24b47150/attachment.html>
Thanks for putting this together Michael. I won't be at EuroLLVM this year, but I'm very interested in the Numerics topic, and I'll be watching this thread. Thanks, -Warren Ristow SN Systems / Sony Interactive Entertainment 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 p.s. (restarting this thread here). Regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190329/d39245ec/attachment.html>
A few things I’ve been thinking about:
* Is anyone working on finishing the migration to using the new fneg
instruction?
* Controls for allowing and/or mandating denormal flushing
* Making denormal-fp-math attribute per FP type
* FTZ flag
* Dealing with constrained and unconstrained versions of target FP
intrinsics
* Can we define a policy or general direction for snan handling?
* Relatedly, llvm.minnum/llvm.maxnum should be renamed to fmin/fmax, and
a new set of minnum/maxnum that follow the defined snan behavior are needed.
This would give 3 complete sets of min/max intrinsics
* Are target features/attributes allowed to change the behavior of
standard operations/intrinsics?
* Adding FP min/max to atomicrmw, and which versions are needed
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of llvm-dev
<llvm-dev at lists.llvm.org>
Reply-To: Michael Berg <michael_c_berg at apple.com>
Date: Friday, March 29, 2019 at 1:05 PM
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
p.s. (restarting this thread here).
Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190329/4c7bc83e/attachment-0001.html>
On Fri, Mar 29, 2019 at 5:51 PM Arsenault, Matthew via llvm-dev < llvm-dev at lists.llvm.org> wrote:> A few things I’ve been thinking about: > > - Is anyone working on finishing the migration to using the new fneg > instruction? > > What did you have in mind? I was not aware that there is work pending.> - Controls for allowing and/or mandating denormal flushing > - Making denormal-fp-math attribute per FP type > - FTZ flag > > This would be useful to us too.> - Dealing with constrained and unconstrained versions of target FP > intrinsics > > That's really interesting and not something that I had anticipated. Itneeds to be discussed... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190401/cf1b6d5f/attachment.html>
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 p.s. (restarting this thread here). Regards, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190403/28f9f105/attachment.html>
>=================== >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>
"Kaylor, Andrew via llvm-dev" <llvm-dev at lists.llvm.org> writes:> ===================> > 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.Yep, we definitely will. This is one of the reasons Simon Moll's predication work (D57504) is so important.> ===================> > Complex types > > ===================> > There, I said it.I'll echo my colleague's response. Oh hell yes! OH HELL YES! :)> ===================> > 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.Indeed. "Fast or not" is too coarse.> ===================> > 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.That's a great idea. -David
I’m working on fneg. I started with the IRBuilder and found that some of the
transformation passes use it. Updating the m_FNeg() matchers gets me farther,
but the InstCombiner doesn’t know how to deal with a non-BinaryOperator.
Sorry for the delay in responding to this thread, but I’ve been out of the
country and am a little behind on email.
--
Kevin P. Neal
SAS/C and SAS/C++ Compiler
Host Research and Development
SAS Institute, Inc.
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
Arsenault, Matthew via llvm-dev
Sent: Friday, March 29, 2019 5:52 PM
To: Michael Berg <michael_c_berg at apple.com>; llvm-dev <llvm-dev at
lists.llvm.org>
Subject: Re: [llvm-dev] EuroLLVM Numerics issues
EXTERNAL
A few things I’ve been thinking about:
* Is anyone working on finishing the migration to using the new fneg
instruction?
* Controls for allowing and/or mandating denormal flushing
* Making denormal-fp-math attribute per FP type
* FTZ flag
* Dealing with constrained and unconstrained versions of target FP
intrinsics
* Can we define a policy or general direction for snan handling?
* Relatedly, llvm.minnum/llvm.maxnum should be renamed to fmin/fmax, and
a new set of minnum/maxnum that follow the defined snan behavior are needed.
This would give 3 complete sets of min/max intrinsics
* Are target features/attributes allowed to change the behavior of
standard operations/intrinsics?
* Adding FP min/max to atomicrmw, and which versions are needed
From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces
at lists.llvm.org>> on behalf of llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Reply-To: Michael Berg <michael_c_berg at apple.com<mailto:michael_c_berg
at apple.com>>
Date: Friday, March 29, 2019 at 1:05 PM
To: llvm-dev <llvm-dev at lists.llvm.org<mailto: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
p.s. (restarting this thread here).
Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190411/b437d2f9/attachment.html>
I was working on threading the #pragma FENV_ACCESS down into clang's AST. But that's on hold because Richard Smith wants more design discussion. The current method I was building on doesn't work for templates. The clang TreeTransform class is magic that I don't grok yet. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Kaylor, Andrew via llvm-dev Sent: Tuesday, April 02, 2019 9:17 PM To: Michael Berg <michael_c_berg at apple.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] EuroLLVM Numerics issues EXTERNAL 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 =================== 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190411/85a83e26/attachment.html>