https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #50 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:41ade3399bd1ec9927be1bb818965831232eda4b
commit r13-6834-g41ade3399bd1ec9927be1bb818965831232eda4b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #49 from Jakub Jelinek ---
Does the has_zero_uses patch work for this? As there is both:
_4 = _6 u> 1.79769313486231570814527423731704356798070567525844996599e+308;
_8 = ~_4;
and _8 has_zero_uses while _4 has uses but all are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #48 from Richard Biener ---
So instead of an extra DCE pass one could try harder to not leave around dead
code after folding, for example with the following (doesn't fix the testcase
yet, all the custom folding code would need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #47 from Jakub Jelinek ---
I have tested the
--- gcc/passes.def.jj 2023-03-22 16:59:45.378390155 +0100
+++ gcc/passes.def 2023-03-22 22:07:35.272803901 +0100
@@ -88,6 +88,7 @@ along with GCC; see the file COPYING3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #46 from Jakub Jelinek ---
And another possibility might be try to keep __builtin_unreachable () in the IL
more often; in this testcase nothing from the __builtin_unreachable () is
really visible in any global ranges, they all are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #45 from Jakub Jelinek ---
For the #c0 foo function, one simple fix would be something like
--- gcc/passes.def.jj 2023-01-02 09:32:39.539037434 +0100
+++ gcc/passes.def 2023-03-22 16:12:57.387652639 +0100
@@ -85,6 +85,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #43 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #42)
> On #c0 foo, this was previously optimized in dom2 which optimized
> _4 = ABS_EXPR ;
> _3 = _4 u>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #42 from Jakub Jelinek ---
On #c0 foo, this was previously optimized in dom2 which optimized
_4 = ABS_EXPR ;
_3 = _4 u> 1.79769313486231570814527423731704356798070567525844996599e+308;
_5 = ~_3;
if (_4 u>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #41 from Jakub Jelinek ---
As for #c1, with trunk -O3 -march=skylake it is:
vmovsd 8(%rdi), %xmm1
vmovsd (%rdi), %xmm0
vmulsd %xmm1, %xmm1, %xmm1
vfmadd132sd %xmm0, %xmm1, %xmm0
vsqrtsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #40 from Jakub Jelinek ---
The current state of #c0 testcase is that bar is actually optimized into return
1;
Folding statement: .ASSUME (_Z3bard._assume.0, x_1(D));
_Z3bard._assume.0 assume inferred range of x_1(D) (param x) =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
Romain Geissler changed:
What|Removed |Added
CC||romain.geissler at amadeus dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #37 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2d5c4a16dd833aa083f13dd3e78e3ef38afe6ebb
commit r13-3924-g2d5c4a16dd833aa083f13dd3e78e3ef38afe6ebb
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #38 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5747470efa8ff0ac82bb5f53d737b29a44f18118
commit r13-3925-g5747470efa8ff0ac82bb5f53d737b29a44f18118
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #36 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2f7f9edd28d75a85a33599978f23811e679e443d
commit r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #35 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #34)
> (In reply to Aldy Hernandez from comment #33)
> > what you're looking for is frange::maybe_isinf.
>
> Again, that works on frange, which I don't have here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #34 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #33)
> (In reply to Jakub Jelinek from comment #31)
> > Created attachment 53873 [details]
> > gcc13-pr107569-div.patch
> >
> > This is what I meant by complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #33 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #31)
> Created attachment 53873 [details]
> gcc13-pr107569-div.patch
>
> This is what I meant by complete nightmare - division.
We can take this to gcc-patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #32 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #31)
> Created attachment 53873 [details]
> gcc13-pr107569-div.patch
>
> This is what I meant by complete nightmare - division.
Ugh, yeah. That's pretty bad.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #31 from Jakub Jelinek ---
Created attachment 53873
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53873=edit
gcc13-pr107569-div.patch
This is what I meant by complete nightmare - division.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #30 from Aldy Hernandez ---
Created attachment 53869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53869=edit
do not set NAN sign in frange::set_nonnegative()
proposed patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #29 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #28)
> (In reply to Aldy Hernandez from comment #27)
> > > As for signed zeros in -fsigned-zeros (default) mode, wonder if we e.g.
> > > don't
> > > say sqrt is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #28 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #27)
> > As for signed zeros in -fsigned-zeros (default) mode, wonder if we e.g.
> > don't
> > say sqrt is nonnegative (even when sqrt (-0.0) is -0.0).
>
> It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #27 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Aldy Hernandez from comment #24)
> > If you single step from there on, we run into:
> >
> > if (gimple_stmt_nonnegative_warnv_p (call,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #26 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #24)
> If you single step from there on, we run into:
>
> if (gimple_stmt_nonnegative_warnv_p (call, _overflow_p))
> r.set_nonnegative (type);
> else if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #25 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #23)
> Created attachment 53866 [details]
> gcc13-pr107569.patch
>
> Updated version of the patch I'll test now (if you don't have any nits).
> Besides the thinko
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #24 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #22)
> Folding statement: _2 = __builtin_pow (1.0e+1, _1);
> Global Exported: _2 = [frange] double [0.0 (0x0.0p+0), +Inf] +NAN
> The +NAN looks suspicious,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
Jakub Jelinek changed:
What|Removed |Added
Attachment #53865|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #22 from Jakub Jelinek ---
Note, I was using:
double
foo (int x, int y)
{
double r;
if (x >= 0)
return 0.0;
switch (y)
{
case 1: r = 0.0; break;
case 2: r = 1.0; break;
default: r = 0.5; break;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #21 from Jakub Jelinek ---
Ok, found a brown paper bag issue in the patch:
--- gcc/range-op-float.cc2022-11-09 21:31:09.420369509 +0100
+++ gcc/range-op-float.cc2022-11-09 21:31:09.420369509 +0100
@@ -1981,7 +1981,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #20 from Jakub Jelinek ---
Created attachment 53865
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53865=edit
gcc13-pr107569.patch
Here is an updated patch (including the incremental patch) with some fixes.
Previous version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #19 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #18)
> Ok, just so that I don't just kibbitz/review frange stuff but also try to do
> something, here is my so far untested attempt at normal multiplication
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #18 from Jakub Jelinek ---
Ok, just so that I don't just kibbitz/review frange stuff but also try to do
something, here is my so far untested attempt at normal multiplication
fold_range (not the x * x stuff discussed elsewhere):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #17 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:4eadbe80060ab6c45193a1a57fac84b035e1c328
commit r13-3860-g4eadbe80060ab6c45193a1a57fac84b035e1c328
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #16 from Jakub Jelinek ---
I've filed PR107591 for the lack of x * x range optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #15 from Jakub Jelinek ---
We don't have multiplication wired in frange, that is something we talked about
today on gcc-patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #14 from Pilar Latiesa ---
I have tested the testcase in comment #1 with Clang, and I realized that Clang
trunk avoids the tailcall to sqrt even without any hint with
__builtin_unreachable: https://godbolt.org/z/5sb8bYcoq
Clang is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #13 from Aldy Hernandez ---
Created attachment 53861
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53861=edit
preprocessed testcase for comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #12 from Aldy Hernandez ---
It looks like the code reading from the blob in SSA_NAME_RANGE_INFO and
populating an frange is always leaving the NAN bit toggled even if it wasn't in
the stored range.
Does this help?
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #11 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > The cdce case is something I've mentioned today:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #10 from Jakub Jelinek ---
So:
--- gcc/range-op-float.cc.jj2022-11-06 11:56:27.138137781 +0100
+++ gcc/range-op-float.cc 2022-11-08 18:13:18.026974667 +0100
@@ -1280,9 +1280,10 @@ foperator_abs::op1_range (frange , tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #9 from Jakub Jelinek ---
Before the
1281 // Then add the negative of each pair:
1282 // ABS(op1) = [5,20] would yield op1 => [-20,-5][5,20].
1283 r.union_ (frange (type,
1284real_value_negate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #8 from Jakub Jelinek ---
Under debugger I see unordered_gt::op1_range coming up with:
[frange] double [-Inf,
1.79769313486231570814527423731704356798070567525844996599e+308
(0x0.f8p+1024)]
which looks right.
But then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #7 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #6)
> __builtin_isfinite (x) is implemented as
> ~UNGT_EXPR, DBL_MAX>.
> So, if we have:
> _3 = ABS_EXPR ;
> _4 = _3 u>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #6 from Jakub Jelinek ---
__builtin_isfinite (x) is implemented as
~UNGT_EXPR, DBL_MAX>.
So, if we have:
_3 = ABS_EXPR ;
_4 = _3 u> 1.79769313486231570814527423731704356798070567525844996599e+308;
_5 = ~_4;
return _5;
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
> The cdce case is something I've mentioned today:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605338.html
> The comparisons in there are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #4 from Jakub Jelinek ---
The cdce case is something I've mentioned today:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605338.html
The comparisons in there are artificial and so unlike user comparisons we
should (if they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #3 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #2)
> Perhaps we should in vrp1 defer removal of __builtin_unreachable (), at least
> the cases where we don't turn that into some useful range?
> That of course
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #2 from Jakub Jelinek ---
Perhaps we should in vrp1 defer removal of __builtin_unreachable (), at least
the cases where we don't turn that into some useful range?
That of course doesn't improve the assume attribute case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
Pilar Latiesa changed:
What|Removed |Added
CC||pilarlatiesa at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
53 matches
Mail list logo
