[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3

["torvalds@linux-foundation.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363

--- Comment #10 from Linus Torvalds <torvalds@linux-foundation.org> ---
(In reply to Richard Biener from comment #9)
> 
> Note alignment has nothing to do with strict-aliasing (-fno-strict-aliasing
> you mean btw).

I obviously meant -fno-strict-aliasing, yes.

But I think it's actually essentially the same issue, just in a different
guise:

> One thing we do is (I'm not 50% sure this explains the observed issue) assume
> that if you have two accesses with type 'short' and they are aligned
> according to this type then they will not partly overlap.  Note this has
> nothing to do with C strict aliasing rules but is basic pointer math when
> you know lower zero bits.

Well, the thing is, you have two situations:

 (a) you can statically see that the two do not alias, because the offset
arithmetic is either constant or you have some range logic that can tell that
they are sufficiently far apart.

 (b) you can't.

Now, everybody is ok with the static aliasing situation in (a). If you can tell
that two addresses don't alias, your'e done, they are independent, there's no
question  about it.

But that's not the situation here. So we're in (b). And what I find personally
so annoying is that gcc has actually *done* that distance check, but apparently
intentionally done it badly based on type information.

And the reason I think this is similar to -fno-strict-aliasing is that it's
that same (b) case, and it looks like a very similar "do a bad job of doing
actual run-time alias analysis based on type information".

It seems to be literally an off-by-one error, not because it generates better
code, but because the compiler has decided to pointlessly make a bad range
comparison based on type.

But I've never worked with the gcc IR dumps, so Andrew Pinski's debug output in
#c5 doesn't actually make me go "ahh, there". Maybe it's that 8 vs 6 that he
pointed out. Did somebody notice that "offset > 8" was off-by-one, and should
have been "offset >= 8"? And then changed it to "offset > 6" which is
off-by-one in the other direction instead?

> I suggest to try the fix suggested in comment#7 and report back if that
> fixes the observed issue.

Vineet?

I still think gcc is doing the wrong thing, exactly because of that
"pointlessly using the wrong range check" issue. This particular code comes
from some old version of zlib, and I can't test because I don't have the ARC
background to make any sense of the generated code.