Hi Micheal, Thanks for the blog post. Just like to point out few things that I thought is related to FP Numerics. LLVM could do some additional transformation with "sqrt" and "division" under fast math on X86 like 1/sqrt(x)* 1/sqrt(x) to 1/x. These are long latency instructions and could get benefit if enabled under unsafe math. Also are we considering doing such FP transforms on vector floating point types? regards, Venkat. On Mon, 1 Apr 2019 at 19:56, Cameron McInally via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hey Michael, > > Thank you for working on this! > > I'd like to touch on a topic mentioned in the blog post. The constrained > intrinsics work is at a road block on how to proceed with the constrained > implementation in the backends, i.e. D55506. Reviews/ideas in this area > would be greatly appreciated (attn: target code owners). > > Thanks, > Cameron > > > On Thu, Mar 28, 2019 at 5:54 PM Michael Berg via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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: >> >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2019_03_llvm-2Dnumerics-2Dblog.html&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=CHHCGUAnxC91rtvrnhhoN0jXGXgXv8EQb8C4XiUEoxY&s=xzUyP83nqSY1h9GrDdHch4INrIFIU-Ycij4S4Tmxdko&e>> >> 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=CHHCGUAnxC91rtvrnhhoN0jXGXgXv8EQb8C4XiUEoxY&s=5CVfTGSHNKAmAzx4dc0HQzDTXMucnDgx_NPimota5m8&e>> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190404/730f7889/attachment.html>
1. Do you have a larger code example that shows the missed sqrt/div
optimization?
We optimize the example you provided already in IR:
#include <math.h>
float sqrt_squared(float x) {
return 1.0f/sqrtf(x) * 1.0f/sqrtf(x);
}
$ clang -O1 -ffast-math -emit-llvm sqrt.c -S -o -
define float @sqrt_squared(float) local_unnamed_addr #0 {
%2 = fdiv fast float 1.000000e+00, %0
ret float %2
}
2. Yes, transforms like the above should work with vector types. If not,
please file a bug.
On Wed, Apr 3, 2019 at 11:47 PM Venkataramanan Kumar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Micheal,
>
> Thanks for the blog post. Just like to point out few things that I
> thought is related to FP Numerics.
> LLVM could do some additional transformation with "sqrt" and
"division"
> under fast math on X86 like 1/sqrt(x)* 1/sqrt(x) to 1/x. These are long
> latency instructions and could get benefit if enabled under unsafe math.
>
> Also are we considering doing such FP transforms on vector floating point
> types?
>
> regards,
> Venkat.
>
>
>
>
>
> On Mon, 1 Apr 2019 at 19:56, Cameron McInally via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hey Michael,
>>
>> Thank you for working on this!
>>
>> I'd like to touch on a topic mentioned in the blog post. The
constrained
>> intrinsics work is at a road block on how to proceed with the
constrained
>> implementation in the backends, i.e. D55506. Reviews/ideas in this
area
>> would be greatly appreciated (attn: target code owners).
>>
>> Thanks,
>> Cameron
>>
>>
>> On Thu, Mar 28, 2019 at 5:54 PM Michael Berg via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> 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:
>>>
>>>
>>>
https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2019_03_llvm-2Dnumerics-2Dblog.html&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=CHHCGUAnxC91rtvrnhhoN0jXGXgXv8EQb8C4XiUEoxY&s=xzUyP83nqSY1h9GrDdHch4INrIFIU-Ycij4S4Tmxdko&e>>>
>>> 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=CHHCGUAnxC91rtvrnhhoN0jXGXgXv8EQb8C4XiUEoxY&s=5CVfTGSHNKAmAzx4dc0HQzDTXMucnDgx_NPimota5m8&e>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190404/846d0de8/attachment.html>
[adding back the mailing list]
Thanks for the example!
define double @_Z12sqrt_squaredd(double) {
%2 = tail call fast double @llvm.sqrt.f64(double %0)
%3 = fdiv fast double 1.000000e+00, %2
%4 = fmul fast double %3, %3
ret double %4
}
So at first look, this has nothing to do with sqrt specifically. We are
missing a basic factorization / re-association for fmul and fdiv:
// (L1 / L2) * (R1 / R2) --> (L1 * R1) / (L2 * R2)
If we do that, then existing transforms should kick in to reduce the sqrt
example. I'll try to fix this in instcombine soon. If you have more
complicated examples where we miss this, that would suggest that we need to
make an enhancement to the "reassociate" pass too.
On Fri, Apr 5, 2019 at 12:26 AM Venkataramanan Kumar <
venkataramanan.kumar.llvm at gmail.com> wrote:
> Hi Sanjay,
>
> On Thu, 4 Apr 2019 at 21:21, Sanjay Patel <spatel at rotateright.com>
wrote:
>
>> 1. Do you have a larger code example that shows the missed sqrt/div
>> optimization?
>>
>> We optimize the example you provided already in IR:
>> #include <math.h>
>> float sqrt_squared(float x) {
>> return 1.0f/sqrtf(x) * 1.0f/sqrtf(x);
>> }
>>
>> Something like this
> #include <math.h>
> double sqrt_squared(double x) {
> double y = 1.0/sqrt(x) ;
> double z = y * y ;
> return z;
> }
> REF: https://godbolt.org/z/2lhnJq
>
>
>> $ clang -O1 -ffast-math -emit-llvm sqrt.c -S -o -
>> define float @sqrt_squared(float) local_unnamed_addr #0 {
>> %2 = fdiv fast float 1.000000e+00, %0
>> ret float %2
>> }
>>
>> 2. Yes, transforms like the above should work with vector types. If
not,
>> please file a bug.
>>
> Oh! thanks let me check.
>
> regards,
> Venkat.
>
>>
>> On Wed, Apr 3, 2019 at 11:47 PM Venkataramanan Kumar via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi Micheal,
>>>
>>> Thanks for the blog post. Just like to point out few things that I
>>> thought is related to FP Numerics.
>>> LLVM could do some additional transformation with "sqrt"
and "division"
>>> under fast math on X86 like 1/sqrt(x)* 1/sqrt(x) to 1/x. These
are long
>>> latency instructions and could get benefit if enabled under unsafe
math.
>>>
>>> Also are we considering doing such FP transforms on vector floating
>>> point types?
>>>
>>> regards,
>>> Venkat.
>>>
>>>
>>>
>>>
>>>
>>> On Mon, 1 Apr 2019 at 19:56, Cameron McInally via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Hey Michael,
>>>>
>>>> Thank you for working on this!
>>>>
>>>> I'd like to touch on a topic mentioned in the blog post.
The
>>>> constrained intrinsics work is at a road block on how to
proceed with the
>>>> constrained implementation in the backends, i.e. D55506.
Reviews/ideas in
>>>> this area would be greatly appreciated (attn: target code
owners).
>>>>
>>>> Thanks,
>>>> Cameron
>>>>
>>>>
>>>> On Thu, Mar 28, 2019 at 5:54 PM Michael Berg via llvm-dev <
>>>> llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> 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:
>>>>>
>>>>>
>>>>>
https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2019_03_llvm-2Dnumerics-2Dblog.html&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=CHHCGUAnxC91rtvrnhhoN0jXGXgXv8EQb8C4XiUEoxY&s=xzUyP83nqSY1h9GrDdHch4INrIFIU-Ycij4S4Tmxdko&e>>>>>
>>>>> 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=CHHCGUAnxC91rtvrnhhoN0jXGXgXv8EQb8C4XiUEoxY&s=5CVfTGSHNKAmAzx4dc0HQzDTXMucnDgx_NPimota5m8&e>>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190405/0690598a/attachment.html>
Hi Sanjay, Thanks, yes I was also thinking of looking at re association pass to see if it can catch few more cases. regards, Venkat. On Fri, 5 Apr 2019 at 19:48, Sanjay Patel <spatel at rotateright.com> wrote:> [adding back the mailing list] > > Thanks for the example! > > define double @_Z12sqrt_squaredd(double) { > %2 = tail call fast double @llvm.sqrt.f64(double %0) > %3 = fdiv fast double 1.000000e+00, %2 > %4 = fmul fast double %3, %3 > ret double %4 > } > > So at first look, this has nothing to do with sqrt specifically. We are > missing a basic factorization / re-association for fmul and fdiv: > // (L1 / L2) * (R1 / R2) --> (L1 * R1) / (L2 * R2) > > If we do that, then existing transforms should kick in to reduce the sqrt > example. I'll try to fix this in instcombine soon. If you have more > complicated examples where we miss this, that would suggest that we need to > make an enhancement to the "reassociate" pass too. > > On Fri, Apr 5, 2019 at 12:26 AM Venkataramanan Kumar < > venkataramanan.kumar.llvm at gmail.com> wrote: > >> Hi Sanjay, >> >> On Thu, 4 Apr 2019 at 21:21, Sanjay Patel <spatel at rotateright.com> wrote: >> >>> 1. Do you have a larger code example that shows the missed sqrt/div >>> optimization? >>> >>> We optimize the example you provided already in IR: >>> #include <math.h> >>> float sqrt_squared(float x) { >>> return 1.0f/sqrtf(x) * 1.0f/sqrtf(x); >>> } >>> >>> Something like this >> #include <math.h> >> double sqrt_squared(double x) { >> double y = 1.0/sqrt(x) ; >> double z = y * y ; >> return z; >> } >> REF: https://godbolt.org/z/2lhnJq >> >> >>> $ clang -O1 -ffast-math -emit-llvm sqrt.c -S -o - >>> define float @sqrt_squared(float) local_unnamed_addr #0 { >>> %2 = fdiv fast float 1.000000e+00, %0 >>> ret float %2 >>> } >>> >>> 2. Yes, transforms like the above should work with vector types. If not, >>> please file a bug. >>> >> Oh! thanks let me check. >> >> regards, >> Venkat. >> >>> >>> On Wed, Apr 3, 2019 at 11:47 PM Venkataramanan Kumar via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> Hi Micheal, >>>> >>>> Thanks for the blog post. Just like to point out few things that I >>>> thought is related to FP Numerics. >>>> LLVM could do some additional transformation with "sqrt" and "division" >>>> under fast math on X86 like 1/sqrt(x)* 1/sqrt(x) to 1/x. These are long >>>> latency instructions and could get benefit if enabled under unsafe math. >>>> >>>> Also are we considering doing such FP transforms on vector floating >>>> point types? >>>> >>>> regards, >>>> Venkat. >>>> >>>> >>>> >>>> >>>> >>>> On Mon, 1 Apr 2019 at 19:56, Cameron McInally via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> Hey Michael, >>>>> >>>>> Thank you for working on this! >>>>> >>>>> I'd like to touch on a topic mentioned in the blog post. The >>>>> constrained intrinsics work is at a road block on how to proceed with the >>>>> constrained implementation in the backends, i.e. D55506. Reviews/ideas in >>>>> this area would be greatly appreciated (attn: target code owners). >>>>> >>>>> Thanks, >>>>> Cameron >>>>> >>>>> >>>>> On Thu, Mar 28, 2019 at 5:54 PM Michael Berg via llvm-dev < >>>>> llvm-dev at lists.llvm.org> wrote: >>>>> >>>>>> 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: >>>>>> >>>>>> >>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.llvm.org_2019_03_llvm-2Dnumerics-2Dblog.html&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=CHHCGUAnxC91rtvrnhhoN0jXGXgXv8EQb8C4XiUEoxY&s=xzUyP83nqSY1h9GrDdHch4INrIFIU-Ycij4S4Tmxdko&e>>>>>> >>>>>> 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=CHHCGUAnxC91rtvrnhhoN0jXGXgXv8EQb8C4XiUEoxY&s=5CVfTGSHNKAmAzx4dc0HQzDTXMucnDgx_NPimota5m8&e>>>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190405/afbea78a/attachment.html>