| Summary: | [4.0 Regression] Aliasing problem with ivopts | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Zdenek Dvorak <rakdver> |
| Component: | tree-optimization | Assignee: | Zdenek Dvorak <rakdver> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | gcc-bugs |
| Priority: | P2 | Keywords: | alias, wrong-code |
| Version: | 4.0.0 | ||
| Target Milestone: | 4.0.0 | ||
| Host: | i686-pc-linux-gnu | Target: | i686-pc-linux-gnu |
| Build: | i686-pc-linux-gnu | Known to work: | |
| Known to fail: | Last reconfirmed: | 2004-09-28 11:37:15 | |
As I said in another bug, this really should not be done with the subtraction at all, on PPC at least it is better to have different IV's for the arrays. Does not ICE wrong keyword, woops :). Subject: Re: [4.0 Regression] Aliasing problem with ivopts
Hello,
> As I said in another bug, this really should not be done with the
> subtraction at all, on PPC at least it is better to have different
> IV's for the arrays.
I do not think the memory reference would get expressed in this way on
PPC (if it does, it is a bug in cost function for ivopts and please
create a bugreport for it). However on i686 this seems to be the best
option, taking the register pressure into account.
Zdenek
Confirmed. Zdenek are you going to apply the patch, it has been approved? Subject: Re: [4.0 Regression] Aliasing problem with ivopts
> Zdenek are you going to apply the patch, it has been approved?
the patch was approved, but after thinking about it more, I noted that
it works by pure luck only, and that the fix for find_base_value
would need to be more complicated.
However in the meantime the patch to prevent ivopts from producing the
type of expressions that caused the problem was commited, so the PR
should no longer reproduce.
Zdenek
Then should we close this bug as fixed or at least move it from being a 4.0 regression? Zdenek, can you check if this bug still makes sense or close it if it does not reproduce anymore? You are the one that knows if there is still an underlying problem to fix or not. The code in find_base_value very likely is not entirely OK, but I do not know about a way how it could cause problems with just the currently used optimizations. Since this code will disappear once we start using results of tree alias analysis at rtl level, I think we can consider the bug fixed. |
The following testcase is misscompiled with -O2 -ftree-loop-ivcanon. The reason is that ivopts rewrite the first loop into (equivalent of) b[0] = 1; b[1] = 2; b[2] = 3; for (tmp = &a, cnt = 3; cnt != 0; tmp += 4B, cnt--) if (*tmp != *(tmp - &a + &b)) { puts ("ERR 1"); break; } Rtl alias analysis concludes that "a" is base for the register in that (tmp - &a + &b) is computed. Store motion than decides that the stores to "b" before the loop are not used inside loop and moves them after the loop, thus causing the error. Reason for this behavior is that the code above is illegal in C (you cannot take difference of two different arrays). However ivopts needs to produce this type of expressions. int a[3] = {1,2,3}; int c[3] = {4,5,6}; int main(void) { int b[3]; int i; b[0] = 1; b[1] = 2; b[2] = 3; for (i = 0; i < 3; i++) if (a[i] != b[i]) { puts ("ERR 1"); break; } b[0] = 4; b[1] = 5; b[2] = 6; for (i = 0; i < 3; i++) if (c[i] != b[i]) { puts ("ERR 2"); break; } return 0; }