On 3/31/23 12:20, Jeff Law wrote:
On 3/31/23 10:12, Hans-Peter Nilsson via Gcc-patches wrote:
Attached. I also removed the bogus warning in Walloc-13.c that no
longer
happens
Add recursive GORI recompuations with a depth limit.
PR tree-optimization/109154
gcc/
* gimple-range-gori.cc (gori_compute::may_recompute_p):
Add depth limit.
* gimple-range-gori.h (may_recompute_p): Add depth param.
* params.opt (ranger-recompute-depth): New param.
gcc/testsuite/
* gcc.dg/Walloca-13.c: Remove bogus warning that is now
fixed.
This patch, commit r13-6945-g429a7a88438cc8, caused a
test-suite regression; FAIL for 'gcc.dg/tree-ssa/pr23109.c
scan-tree-dump-not recip "reciptmp"' for cris-elf that I
logged at PR109363.
Perhaps it's somewhat of a similar nature as Walloca-13.c
but then again it's not an bogus warning that's gone.
Is it expected and I should just blankly xfail it or is it
worth more attention? I'm a bit surprised that it hasn't
shown up for other targets though.
I already let Andrew know -- it's affecting a ton of targets. It may
be the case that we just need to adjust the param for that test.
So the test fails in the testuite because a recip has been put into the
code, but does it execute OK? or maybe thats not testable?
with the recompuation, we make some signficant changes:
e.0_1 = e;
d_12 = e.0_1 * 2.0e+0;
E_13 = 1.0e+0 - d_12;
goto <bb 9>; [INV]
<bb 3> :
if (e.0_1 >
5.00000000000000010408340855860842566471546888351440429688e-3)
goto <bb 4>; [INV]
else
goto <bb 8>; [INV]
<bb 4> :
if (E_13 > 1.0e+0)
goto <bb 5>; [INV]
else
goto <bb 6>; [INV]
In EVRP we now determine that the branch in BB4 is never true and we
reduce the testcase significantly
We end up now with:
<bb 2> [local count: 357878152]:
e.0_1 = e;
if (e.0_1 >
5.00000000000000010408340855860842566471546888351440429688e-3)
goto <bb 3>; [50.00%]
else
goto <bb 4>; [50.00%]
<bb 3> [local count: 178939076]:
d_9 = e.0_1 * 2.0e+0;
E_10 = 1.0e+0 - d_9;
_16 = E_10 - 1.0e+0;
reciptmp.5_21 = 1.0e+0 / d_9;
And with
d_9 : [frange] double
[1.0000000000000001942890293094023945741355419158935546875e-2
(0x0.a3d70a3d70a3ep-6), +Inf]
I guess it figures the recip is safe to put in, there will not be a
divide by zero.
I guess the test is no longer testing what it should be?
And yes, we could set he param back to 1 for the test...
add --param=ranger-recompute-depth=1 makes the "issue" go away :-)
for now.
Andrew
