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

[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

[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 Phosit  ---
When there are few iterations (likely when it is unroled) there is no
alias-check:

void fill(int* data, int& value)
{
for(unsigned long i{0}; i != 4; ++i)
data[i] = value;
}

--- at -O2 results in:
fill(int*, int&):
movdxmm1, DWORD PTR [rsi]
pshufd  xmm0, xmm1, 0xe0
movqQWORD PTR [rdi], xmm0
movdxmm0, DWORD PTR [rsi]
pshufd  xmm0, xmm0, 0xe0
movqQWORD PTR [rdi+8], xmm0
ret

---
At -O3 the loop isn't removed and (thus) there is an alias-check.

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

[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 dependence info so a later
invariant motion pass could do this.

There is a missed optimization for regular invariant motion or rather
TBAA alias analysis.  While osmesa->buffer might point to the clearpixel
member, once we advance to the buffer member we may no longer access the
clearpixel member via the osmesa_context structure (storing via unsigned
int into buffer makes the dynamic type of the context no longer
osmesa_context).
But it's hard to exploit this I think.

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

[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 vectorization part is done now, then why did you make this block
the vectorizer meta-bug? I mean, if that's the part that works and it's only
the other stuff that's still in need of fixing...

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

[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||53947
   Assignee|irar at il dot ibm.com |unassigned at gcc dot 
gnu.org

--- Comment #6 from Richard Biener  ---
Reconfirmed.  Note we do vectorize the loop now but we add a runtime check
for the aliasing (and not move the invariant out either).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

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

[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 #5 from Eric Gallager  ---
(In reply to Ira Rosen from comment #2)
> Created attachment 7916 [details]
> Full testcase

Are you still working on this at all?

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

[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
osmesa-clearpixel).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347

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

[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

 CC||dberlin at gcc dot gnu dot
   ||org
   Keywords||alias
   Last reconfirmed|2005-05-04 18:15:55 |2005-10-24 00:20:32
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347

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

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Last reconfirmed|2005-01-09 15:55:15 |2005-04-11 06:09:59
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347

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

[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 structure-aliasing branch).

-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2005-01-09 15:55:15
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347