[Bug tree-optimization/19347] Invariant load not moved out of loop

2024-01-03 Thread phosit at autistici dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347 --- Comment #10 from Phosit --- The analysis in my previous comment is wrong. I don't know why there is no alias-check at -O2. Also the loop _is_ removed at -O3.

[Bug tree-optimization/19347] Invariant load not moved out of loop

2024-01-03 Thread phosit at autistici dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347 Phosit changed: What|Removed |Added CC||phosit at autistici dot org --- Comment #9 from

[Bug tree-optimization/19347] Invariant load not moved out of loop

2019-06-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347 --- Comment #8 from Richard Biener --- The vectorizer already moves the load out of the loop after the runtime alias-check. The vectorizer could hoist the load out of the scalar epilogue loop, that's missing, or it could annotate refs with depen

[Bug tree-optimization/19347] Invariant load not moved out of loop

2019-06-22 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347 --- Comment #7 from Eric Gallager --- (In reply to Richard Biener from comment #6) > Reconfirmed. Note we do vectorize the loop now but we add a runtime check > for the aliasing (and not move the invariant out either). So wait if the vectorizat

[Bug tree-optimization/19347] Invariant load not moved out of loop

2018-03-02 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347 Richard Biener changed: What|Removed |Added Last reconfirmed|2006-02-16 21:28:32 |2018-3-2 Blocks|

[Bug tree-optimization/19347] Invariant load not moved out of loop

2018-03-02 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment

[Bug tree-optimization/19347] Invariant load not moved out of loop

2009-04-03 Thread rguenth at gcc dot gnu dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-03 12:06 --- The store to *ptr aliases the load from osmesa->clearpixel - there is no (easy) way to otherwise prove that it is not (at least with the testcase). We do not see where osmesa->buffer points to (it may point to &osmes

[Bug tree-optimization/19347] Invariant load not moved out of loop

2005-10-23 Thread pinskia at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-24 00:20 --- This is the normal, we need offset/varaible aliasing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug tree-optimization/19347] Invariant load not moved out of loop

2005-04-10 Thread pinskia at gcc dot gnu dot org
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2005-01-09 1

[Bug tree-optimization/19347] Invariant load not moved out of loop

2005-01-09 Thread pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:55 --- Confirmed but add a full testcase here, thanks. Actually I don't think it would require whole program analysis to do this in LIM (or LICM), we just need more information (which might be done on the struct