public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/103723] New: Loop invariant motion pass failed to remove unused code from loop
@ 2021-12-15 2:54 lingling.kong7 at gmail dot com
2021-12-15 11:39 ` [Bug tree-optimization/103723] zero extend not moved out of the loop after IV-OPTS pinskia at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: lingling.kong7 at gmail dot com @ 2021-12-15 2:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103723
Bug ID: 103723
Summary: Loop invariant motion pass failed to remove unused
code from loop
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lingling.kong7 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/b7x1s5Yrn
For this case, the instruction `mov ecx, eax` in bb `.L3` could remove
from loop body and could sink to '.L8' and '.L1'.
After ivopt pass the tree dump is:
uint32_t test (uint32_t buf_avail,
const uint8_t * buf, const uint8_t * buf_back)
{
sizetype ivtmp.7;
uint32_t len_test;
unsigned char _3;
sizetype _4;
unsigned char _6;
sizetype _7;
unsigned int _15;
unsigned int _16;
unsigned int _17;
<bb 2> [local count: 114863530]:
if (buf_avail_8(D) > 2)
goto <bb 6>; [94.50%]
else
goto <bb 8>; [5.50%]
<bb 8> [local count: 6317494]:
goto <bb 5>; [100.00%]
<bb 6> [local count: 108546036]:
_15 = buf_avail_8(D) + 4294967293;
_7 = (sizetype) _15;
_4 = _7 + 3;
goto <bb 4>; [100.00%]
<bb 3> [local count: 958878296]:
_16 = (unsigned int) ivtmp.7_19;
len_test_12 = _16 + 1;
ivtmp.7_18 = ivtmp.7_19 + 1;
if (ivtmp.7_18 != _4)
goto <bb 7>; [94.50%]
else
goto <bb 9>; [5.50%]
<bb 9> [local count: 52738306]:
# len_test_21 = PHI <len_test_12(3)>
goto <bb 5>; [100.00%]
<bb 7> [local count: 906139990]:
<bb 4> [local count: 1014686026]:
# ivtmp.7_19 = PHI <ivtmp.7_18(7), 2(6)>
_17 = (unsigned int) ivtmp.7_19;
len_test_13 = _17;
_3 = MEM[(const uint8_t *)buf_9(D) + ivtmp.7_19 * 1];
_6 = MEM[(const uint8_t *)buf_back_11(D) + ivtmp.7_19 * 1];
if (_3 == _6)
goto <bb 3>; [94.50%]
else
goto <bb 10>; [5.50%]
<bb 10> [local count: 55807731]:
# len_test_20 = PHI <len_test_13(4)>
<bb 5> [local count: 114863531]:
# len_test_14 = PHI <len_test_21(9), len_test_20(10), 2(8)>
return len_test_14;
}
len_test_13 is unused in loop body and could sink to bb 5.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/103723] zero extend not moved out of the loop after IV-OPTS
2021-12-15 2:54 [Bug tree-optimization/103723] New: Loop invariant motion pass failed to remove unused code from loop lingling.kong7 at gmail dot com
@ 2021-12-15 11:39 ` pinskia at gcc dot gnu.org
2021-12-15 11:45 ` pinskia at gcc dot gnu.org
2022-01-04 11:24 ` [Bug tree-optimization/103723] zero extend not sunk out of the loop after IV-OPTS in the sink pass rguenth at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-15 11:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103723
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-12-15
Summary|Loop invariant motion pass |zero extend not moved out
|failed to remove unused |of the loop after IV-OPTS
|code from loop |
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>For this case, the instruction `mov ecx, eax` in bb `.L3` could remove from loop body and could sink to '.L8' and '.L1'.
Right the problem is not what you referenced in the comment #0 though, it is
the following instead:
_4 = (unsigned int) ivtmp.7_15;
That is a truncate from 64bit to 32bit.
There is no pass after IV-OPTS that sinks the zero extend out of the loop
though. LIM on the gimple level is not doing it for some reason ...
At Lim4 we have:
<bb 4> [local count: 1014686026]:
# ivtmp.7_15 = PHI <ivtmp.7_7(7), 2(6)>
_4 = (unsigned int) ivtmp.7_15;
len_test_13 = _4;
_3 = MEM[(const uint8_t *)buf_9(D) + ivtmp.7_15 * 1];
_6 = MEM[(const uint8_t *)buf_back_11(D) + ivtmp.7_15 * 1];
if (_3 == _6)
goto <bb 3>; [94.50%]
else
goto <bb 10>; [5.50%]
<bb 10> [local count: 55807731]:
# len_test_16 = PHI <len_test_13(4)>
I don't know enough about LIM if it was designed to handle non stores to sink
but maybe it should.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/103723] zero extend not moved out of the loop after IV-OPTS
2021-12-15 2:54 [Bug tree-optimization/103723] New: Loop invariant motion pass failed to remove unused code from loop lingling.kong7 at gmail dot com
2021-12-15 11:39 ` [Bug tree-optimization/103723] zero extend not moved out of the loop after IV-OPTS pinskia at gcc dot gnu.org
@ 2021-12-15 11:45 ` pinskia at gcc dot gnu.org
2022-01-04 11:24 ` [Bug tree-optimization/103723] zero extend not sunk out of the loop after IV-OPTS in the sink pass rguenth at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-15 11:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103723
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Actually this is more complex, I had missed the original add too.
the full loop:
<bb 3> [local count: 958878296]:
_18 = (unsigned int) ivtmp.7_15;
len_test_12 = _18 + 1;
ivtmp.7_7 = ivtmp.7_15 + 1;
if (ivtmp.7_7 != _21)
goto <bb 7>; [94.50%]
else
goto <bb 9>; [5.50%]
<bb 9> [local count: 52738306]:
# len_test_17 = PHI <len_test_12(3)>
goto <bb 5>; [100.00%]
<bb 7> [local count: 906139990]:
<bb 4> [local count: 1014686026]:
# ivtmp.7_15 = PHI <ivtmp.7_7(7), 2(6)>
_4 = (unsigned int) ivtmp.7_15;
len_test_13 = _4;
_3 = MEM[(const uint8_t *)buf_9(D) + ivtmp.7_15 * 1];
_6 = MEM[(const uint8_t *)buf_back_11(D) + ivtmp.7_15 * 1];
if (_3 == _6)
goto <bb 3>; [94.50%]
else
goto <bb 10>; [5.50%]
<bb 10> [local count: 55807731]:
# len_test_16 = PHI <len_test_13(4)>
We can't just sink the cast though as that would violate the closed-loop-SSA.
We would need to sink also:
_18 = (unsigned int) ivtmp.7_15;
len_test_12 = _18 + 1;
Which we do at the RTL level ....
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/103723] zero extend not sunk out of the loop after IV-OPTS in the sink pass
2021-12-15 2:54 [Bug tree-optimization/103723] New: Loop invariant motion pass failed to remove unused code from loop lingling.kong7 at gmail dot com
2021-12-15 11:39 ` [Bug tree-optimization/103723] zero extend not moved out of the loop after IV-OPTS pinskia at gcc dot gnu.org
2021-12-15 11:45 ` pinskia at gcc dot gnu.org
@ 2022-01-04 11:24 ` rguenth at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-01-04 11:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103723
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|zero extend not moved out |zero extend not sunk out of
|of the loop after IV-OPTS |the loop after IV-OPTS in
| |the sink pass
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note there's pass_sink_code after IVOPTs which is what is designed to perform
sinking. That is probably confused by seeing
<bb 5> [local count: 1014686026]:
# ivtmp.7_15 = PHI <ivtmp.7_7(7), 2(3)>
_4 = (unsigned int) ivtmp.7_15;
_3 = MEM[(const uint8_t *)buf_9(D) + ivtmp.7_15 * 1];
_6 = MEM[(const uint8_t *)buf_back_11(D) + ivtmp.7_15 * 1];
if (_3 == _6)
goto <bb 4>; [94.50%]
else
goto <bb 10>; [5.50%]
<bb 10> [local count: 55807731]:
<bb 6> [local count: 114863531]:
# len_test_14 = PHI <len_test_12(9), _4(10), 2(8)>
return len_test_14;
where it doesn't consider inserting on edges because usually the pred works
fine but here it's a no-op sink and splitting the edge might be profitable
because its a loop exit.
So the sinking pass needs tweaking for such case (but _not_ split the edge
in case the PHI use is on a simple merge)
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-01-04 11:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-15 2:54 [Bug tree-optimization/103723] New: Loop invariant motion pass failed to remove unused code from loop lingling.kong7 at gmail dot com
2021-12-15 11:39 ` [Bug tree-optimization/103723] zero extend not moved out of the loop after IV-OPTS pinskia at gcc dot gnu.org
2021-12-15 11:45 ` pinskia at gcc dot gnu.org
2022-01-04 11:24 ` [Bug tree-optimization/103723] zero extend not sunk out of the loop after IV-OPTS in the sink pass rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).