[Bug tree-optimization/110942] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1165-g257c2be7ff8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jeffrey A. Law --- Per c#5
[Bug tree-optimization/110942] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1165-g257c2be7ff8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942 Martin Jambor changed: What|Removed |Added Keywords|needs-bisection | CC||jamborm at gcc dot gnu.org --- Comment #5 from Martin Jambor --- This has been fixed with r14-5109-ga291237b628f41 (Andrew MacLeod: Remove simple ranges from trailing zero bitmasks.)
[Bug tree-optimization/110942] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1165-g257c2be7ff8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #4 from Andrew Pinski --- Seems to be fixed on the trunk.
[Bug tree-optimization/110942] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1165-g257c2be7ff8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942 --- Comment #3 from Andrew Macleod --- The original revision listed, I narrowed down to a single instance where the new code did something that makes a difference we determine that in stmt stmt _8 = (int) i_10; which originally had a range of int [0, 0][8, 8] MASK 0x8 VALUE 0x0, the new code allows it to determine that the result is actually now int [0, 0], which allows stmt_8 to be propagated as "0" now.. and thus dead. It was also dead before, but stayed around for a fe wpasses because it wasnt a constant, so wasn't put in the "let VRP kill this stmt because it was fully propagated as a constant" list. The only difference in the IL as a result is the block which contained that stmt has a phi: >: > # k_14 = PHI > _8 = (int) i_10; and with the current trunk, we remove that block, which causes the fallthru block to have an extra incoming edge: < # i_10 = PHI <0(4), 8(25), 8(10), 0(3)> < # k_15 = PHI <0(4), k_13(25), k_15(10), 0(3)> --- > # i_10 = PHI <0(4), 8(26), 0(3)> > # k_15 = PHI <0(4), k_14(26), 0(3)> That is literally the only difference coming out of EVRP, so perhaps the extra edge coming into the block is causing some threading issues?
[Bug tree-optimization/110942] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1165-g257c2be7ff8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed. The problem seems like missing jump threading: [local count: 114235120]: # j_4 = PHI if (j_4 <= 4) goto ; [84.84%] else goto ; [15.16%]
[Bug tree-optimization/110942] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1165-g257c2be7ff8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942 --- Comment #1 from Andrew Macleod --- Created attachment 55743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55743=edit patch to revert the change Although the bisection stopped at this change, it does not appear to be the underlying culprit. The attached patch will revert that change (its pretty simple) and the problem still exists.. so something other than that presumably caused it. I Also presume this is the first change going backwards that shows the issue, is it possible to find the *first* change since gcc 13 was branched that caused the issue?
[Bug tree-optimization/110942] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1165-g257c2be7ff8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110942 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
