Tool for detecting pointer aliasing problems in C / C++

Question

Is there a tool that can do alias analysis on a program and tell you where gcc / g++ are having to generate sub-optimal instruction sequences due to potential pointer aliasing?

Answer 1

I don't know of anything that gives "100 %" coverage, but for vectorizing code (which aliasing often prevents) use the -ftree-vectorizer-verbose=n option, where n is an integer between 1 and 6. This prints out some info why a loop couldn't be vectorized.

For instance, with g++ 4.1, the code

//#define RSTR __restrict__
#define RSTR

void addvec(float* RSTR a, float* b, int n)
{
  for (int i = 0; i < n; i++)
    a[i] = a[i] + b[i];
}

results in

$ g++ -ftree-vectorizer-verbose=1 -ftree-vectorize -O3 -c aliastest.cpp

aliastest.cpp:6: note: vectorized 0 loops in function.

Now, switch to the other definition for RSTR and you get

$ g++ -ftree-vectorizer-verbose=1 -ftree-vectorize -O3 -c aliastest.cpp

aliastest.cpp:6: note: LOOP VECTORIZED.
aliastest.cpp:6: note: vectorized 1 loops in function.

Interestingly, if one switches to g++ 4.4, it can vectorize the first non-restrict case by versioning and a runtime check:

$ g++44 -ftree-vectorizer-verbose=1 -O3 -c aliastest.cpp

aliastest.cpp:6: note: created 1 versioning for alias checks.

aliastest.cpp:6: note: LOOP VECTORIZED.
aliastest.cpp:4: note: vectorized 1 loops in function.

And this is done for both of the RSTR definitons.

Answer 2

In the past I've tracked down cases aliasing slowdowns with some help from a profiler. Some of the game console profilers will highlight parts of the code that are causing lots of load-hit-store penalties - these can often occur because the compiler assumes some pointers are aliased and has to generate the extra load instructions. Once you know the part of the code they're occuring, you can backtrack from the assembly to the source to see what might be considered aliased, and add "restict" as needed (or other tricks to avoid the extra loads).

I'm not sure if there are any freely available profilers that will let you get into this level of detail, however.

The side benefit of this approach is that you only spend your time examining cases that actually slow your code down.