https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #19 from Pilar Latiesa ---
The testcase:
#include
struct TVec { double x, y, z; };
double dot(TVec const &u, TVec const &v)
{ return u.x * v.x + u.y * v.y + u.y * v.y + u.z * v.z; }
double mag(TVec const &u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #18 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=107591
--- Comment #17 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > I've screwed up the real_value_negate calls, they need to assign the result.
> >
> > Anyway, yet another opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #16 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #15)
> I've screwed up the real_value_negate calls, they need to assign the result.
>
> Anyway, yet another option would be for cdce to ask the ranger if the sqrt
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #15 from Jakub Jelinek ---
I've screwed up the real_value_negate calls, they need to assign the result.
Anyway, yet another option would be for cdce to ask the ranger if the sqrt
argument can be smaller than -0.0 (and only if it can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #14 from Jakub Jelinek ---
Incremental patch on top of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569#c18 patch which optimizes
the floating point x * x:
--- gcc/range-op-float.cc.jj2022-11-09 19:06:11.075716000 +0100
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #13 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Andrew Macleod from comment #11)
> > no, I meant in addition to the VREL_EQ. so
> > if (rel == VREL_EQ && op1_range != op2_range)
> > th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #12 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #11)
> no, I meant in addition to the VREL_EQ. so
> if (rel == VREL_EQ && op1_range != op2_range)
> then you know you have something like if (x == y) z=x*y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Andrew Macleod from comment #9)
> > you could also test whether op1_range contains + and/or - 0, as well as
> > op2_range. VREL_EQ is a symbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #10 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #9)
> you could also test whether op1_range contains + and/or - 0, as well as
> op2_range. VREL_EQ is a symbolic equality.. the ranges can still be
> distinct and i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Aldy Hernandez from comment #6)
> > FYI, the range operators have a relation field, so it should be able to tell
> > you that both operands are equ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #8 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #6)
> FYI, the range operators have a relation field, so it should be able to tell
> you that both operands are equal with VREL_EQ (?). You could use that to
> optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #7 from Jakub Jelinek ---
To answer my own question:
int
foo (int x)
{
return x + x;
}
int
bar (int x)
{
return x * x * x * x * x * x;
}
float
baz (float x)
{
return x + x;
}
float
qux (float x)
{
return x * x * x * x * x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #6 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #2)
> Perhaps before we try to map MULT_EXPR into some irange/frange op the usual
> way,
> while we still have access to gimple statement check if it is MULT_EXPR wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #5 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Aldy Hernandez from comment #1)
> > pinskia is a god. How does he keep track of all these bugs, plus the cross
> > reference between them? I knew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #3 from Andrew Pinski ---
(In reply to Aldy Hernandez from comment #1)
> pinskia is a god. How does he keep track of all these bugs, plus the cross
> reference between them? I knew PR91645 was related, but it was specifically
> som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #2 from Jakub Jelinek ---
Perhaps before we try to map MULT_EXPR into some irange/frange op the usual
way,
while we still have access to gimple statement check if it is MULT_EXPR with
the same operands and use a different artificial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #1 from Aldy Hernandez ---
pinskia is a god. How does he keep track of all these bugs, plus the cross
reference between them? I knew PR91645 was related, but it was specifically
something on my radar, not the 5 trillion bugs in pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-11-09
Ever confirmed|0
20 matches
Mail list logo
