Aliasing brokenness (Was: Re: [patch RFC] SH: Use FRAME_GROWS_DOWNWARD)

[Mark Mitchell]

I've reviewed this and the related threads.

First, I agree with Joseph that the current standard simply doesn't say 
what the right answer is, and that there's no obvious forthcoming 
statement from the committee.  People can try to parse the standard to 
find an answer, but that's not useful; I don't think that the people who 
wrote those words really had an answer in mind.  The various papers are 
useful, but they're not even necessarily indicative of a direction on 
this issue.

Second, as the original implementor of type-based aliasing in GCC, I 
researched these issues pretty carefully.  The motivating example was 
that the SGI compiler for MIPS (later the Open64 compiler) performed 
type-based aliasing, and that generated much better code.  It did this 
by default, at -O2, if I recall correctly.  It did not believe that the 
mere presence of a union somewhere prevented it from doing the 
optimization; the access had to be through the union itself.

That's the rule we've tried to use in GCC, as well; that if "p" and "q" 
pointer to distinct types (not part of the same alias set) then 
modifying "*p" cannot change the value of "*q", unless both accesses are 
directly through a union.  I don't know that the front ends and 
optimizers are careful about preserving the user's access through 
unions, but they could in theory be appropriately careful.

Given the murkiness of the standard, I think that's a sensible 
compromise; it permits optimization, but gives users a way to explicitly 
do type-punning where required.  This approach also seems reasonably 
consonant with the paper referenced earlier in this thread.

I don't think any special handling is required for initial sequences; if 
S and T are types with a common initial sequence, then they should 
probably be in the same alias set anyhow, so that modifications to an S 
are flagged as possibly modifying a T.  At the least, field types in the 
initial sequence should conflict with both S and T.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304