This is the mail archive of the gcc@gcc.gnu.org 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: strict aliasing benefit examples


> 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.

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.

For C++, it is the same except replace type with dynamic type.
so you can do, hopefully I have the syntax correct for placement news):
int *a = new int;
use (a)
float *b = new(a) float;
use (b)

> Realistic code matters. Contrived examples won't
> convince anyone.

Realistic code for aliasing questions are usually going
to be big and hard to understand.

> 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.

> 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.

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.

Thanks,
Andrew Pinski


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