This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]