> It doesn't help that the standards are only available for $$$ or > as contraband.
It's an unfortunate cultural issue that C programmers traditionally don't use the standard on a regular basis. There are other languages where a programmer would never think of writing code without a language reference manual close at hand. > Problem: people don't write code that way. (well I hope not) > People declare a few local variables, load them with data via > the pointers, do stuff with the local variables, then save back > the results via the pointers. Why do you hope that people write code that does manually what an optimizer should be doing? C is an interesting language in that there are a lot of long-time C programmers who view C as not much more than a high-level assembler language and write code in that style. But there are also a lot of people who view it just as some high-level language with standardized semantics and don't give any thought at all to what the resulting code of their program will look like. Unfortunately, there don't seem to be very many C programmers in the middle, which would probably be the most appropriate way to use the language. > I think there are 3 aliasing possibilities here: > > 1. known to alias > 2. known to not alias > 3. may alias By "alias" here, I think you mean what's more commonly called "conflict". If so, sure: you're constantly building information about sets of references to determine which are known to be the same, which are known not to conflict, and which we can't tell anything about. > You could start with a base+offset pass that only distinguishes the > known-to-alias cases from the others. That deals with typical casts. > Then you follow that with type-based analysis and finally back to > base+offset to find a few remaining known-to-not-alias cases. Not sure what the purpose of redoing the first phase again would be, but basically what you state is an oversimplification of what's done. > The current situation really hurts. For example, any project using the > wxWidgets library must use -fno-strict-aliasing. In that case, the library isn't written in valid C and those bugs should be fixed. > If you want performance, disallow aliasing in unions. :-) Almost nobody > was doing that until it got suggested as a way to make gcc cooperate. > Even today it is very rare. People use unions to save space; this should > not hurt performance. I'm sorry, I don't follow.
