This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: strict aliasing benefit examples
On 11/28/06, Andrew Pinski <pinskia@physics.uc.edu> wrote:
> I often need to convince people that gcc is not just
> defective for doing random nonsense to code which
> violates the C and C++ aliasing rules. Not that I'm
> real sure myself actually, given that gcc is able to
> generate warnings for all the normal cases, but anyway...
> I'm up against the idea that Visual Studio is correct
> and gcc is buggy crap. :-) Very few professional
> software developers can handle the aliasing issue.
The aliasing rules are not hard to understand.
For a long-time gcc developer like you, certainly.
It doesn't help that the standards are only available
for $$$ or as contraband. Anyway, I've never seen a
book or course that teaches any of this stuff.
Simplified rules for C:
Only access a variable by its own type, its signed or
unsigned variant, or by the character types (char, unsigned char,
and signed char). For structs/unions, accessing it via
an inner struct/union is also ok.
How about an outer struct? For example, Linux does that
all the time to recover driver-specific data from a generic
struct without needing an extra pointer.
> Realistic code matters. Contrived examples won't
> convince anyone.
Realistic code for aliasing questions are usually going
to be big and hard to understand.
Bummer. I'm trying to resist the normal fix, which is
to consider strict-aliasing as a benchmark cheat that
you have to disable for real-world code.
> People care about 32-bit x86, not IA-64. AMD64 and
> PowerPC count for something, but not much.
Actually PowerPC code generation counts a lot for me, as I
work for Sony.
It counts for me too, at home. My only computer is a
Mac G4 Cube with the MPC7400.
It doesn't count at work, where Win32 is the norm.
> The best examples would involve optimizations which
> could not be performed if gcc did what people normally
> expect from a simple pointer cast and wrong-type access.
> I doubt such examples exist, but I hope they do.
An easy quick example of what strict alias can do is the following:
int f(int *a, float *b)
{
*a = 1;
*b = 2.0;
return *a == 2;
}
Without the aliasing rules provided by the C/C++ standard,
you would not know if *a could alias *b, therefor not always return 0.
I have an example kind of like that, though for __restrict
because there is a (char*) in it.
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.
So that won't convince many Visual Studio 2005 fans. :-(
The reason why GCC gets the cast case "wrong" is because GCC does
not do that much base+offset based aliasing but instead it implements
type based aliasing.
What most other compilers do is first base+offset aliasing and then
type based aliasing if they cannot figure that out with the base+offset.
We have found that we currently get better results with our current IR,
with type based aliasing first.
I think there are 3 aliasing possibilities here:
1. known to alias
2. known to not alias
3. may alias
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.
The current situation really hurts. For example, any project using the
wxWidgets library must use -fno-strict-aliasing. That means you get
no benefit from __restrict if you use wxWidgets. (because __restrict
is collateral damage when -fno-strict-aliasing gets used)
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.