http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

void CrossProductNoStackCopy( Vector *out, Vector *in1, Vector *in2 )
{
  out->x = in1->y * in2->z - in1->z * in2->y ;
  out->y = in1->z * in2->x - in1->x * in2->z ;
  out->z = in1->x * in2->y - in1->y * in2->x ;
}

if out and in1 were the same pointer.

But if you really really needed to make the determination at runtime I guess you could do something like

void func(int *a, int *b)
{
   if ( a == b )
   {
      // aliased code
   }
   else
   {  // we know they are not aliased
      int * __restrict pA = a;
      int * __restrict pB = b;
      // nonaliased code runs on pA and pB
   }
}

which trades the 40-cycle LHS for a 5-20 cycle branch stall.

Anyways, What I was wondering whether its possible to tell ( or modify ) the compiler to _assume_ pointers are unaliased and insert code containing LHS inside the a branch ( which tests whether the pointers are aliased or not during runtime ).

why whould we need this ?

Obviously the profiling tools can point out the bits of code which are actually causing the pipeline stalls, but in some cases its not possible to refactor or know whether we can _actually_ use the restrict keyword.

With failsafe code within a branch ( which can be predicted to be false most of the time …) to care of the rare condition of aliasing, I think it will make the job of profiling/re-coding/profiling..

Ofcourse, this also depends on the assumption that a branch would be less expensive than a stall…

int CFoo::MemberFuncWithRestrict( int * a, int x )
{
m_iBar = x;
*a = 7;
return m_iBar + *a;
}

What’s supposed to happen is that it sets m_iBar to a number. then the contents of pointer a to 7, and then adds m_iBar to whatever’s through pointer a. With parameters of (&m_iBar, 5), what should happen is that *a and m_iBar are the same thing, so m_iBar should get set to 7 at line two, and then return 7+7=14. The compiler does this by reloading m_iBar from memory after *a = 7.

With __restrict, you have promised the compiler that a ≠ &m_iBar, so it does not reload m_iBar. Instead, it assumes that m_iBar is still 5 (and not 7) after the assignment to *a, and returns 5+7 = 12.

you will get incorrect results, in this case a return value of 12 instead of 14.

Did you mean

you will get incorrect results, in this case a return value of 14 instead of 12.

In any case having ints and floats aliased like this is a contrived example and rather silly. The more likely case is two pointers of the same type.

Compiler can assume that a and b don’t alias, because if they do alias, it’s a violation of strict aliasing rules (the calling code with (float*)(foo + 1) contains this violation). Whether the compiler actually assumes it of course depends on implementation and optimization settings.