Bug 19347 - Invariant load not moved out of loop
Summary: Invariant load not moved out of loop
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.0.0
: P2 enhancement
Target Milestone: ---
Assignee: Ira Rosen
URL:
Keywords: alias, missed-optimization
Depends on:
Blocks:
 
Reported: 2005-01-09 10:50 UTC by Ira Rosen
Modified: 2009-04-03 12:06 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-02-16 21:28:32


Attachments
Full testcase (440 bytes, text/plain)
2005-01-10 06:23 UTC, Ira Rosen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ira Rosen 2005-01-09 10:50:41 UTC
In mesa benchmark (osmesa.c:678) 

         GLuint i, n, *ptr4;
         n = osmesa->rowlength * osmesa->height;
         ptr4 = (GLuint *) osmesa->buffer;
         for (i=0;i<n;i++) {
            *ptr4++ = osmesa->clearpixel;
         }   

The load of osmesa->clearpixel is not taken outside the loop by LIM because of 
aliasing limitations. This in turn also prevents vectorization.

In this particular case we can actually get the load moved out of the loop even 
without resolving the aliasing issue (which requires whole-program), on 
account that even if the store aliases the load, it will not alter the value 
loaded (because we store the same value that we loaded).

I'm looking into this in the context of the vectorizer.
Comment 1 Andrew Pinski 2005-01-09 15:55:15 UTC
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).
Comment 2 Ira Rosen 2005-01-10 06:23:50 UTC
Created attachment 7916 [details]
Full testcase
Comment 3 Andrew Pinski 2005-10-24 00:20:32 UTC
This is the normal, we need offset/varaible aliasing.
Comment 4 Richard Biener 2009-04-03 12:06:35 UTC
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).