Basic AA fail. Bug or feature?

basicaa with pointers to distinct globals.

static const int x = 4;
static const int y = 5;
static const double z = 6.0;

int types_match(void)
return (char*)&x == (char*)&y;

int types_differ(void)
return (char*)&x == (char*)&z;

I’d like both tests to resolve to ‘false’ at the IR level, but the mixed type one doesn’t at O3:

target triple = “x86_64-unknown-linux-gnu”
@x = internal constant i32 4, align 4
@z = internal constant double 6.000000e+00, align 8

define i32 @types_match() {
ret i32 0

define i32 @types_differ() {
ret i32 zext (i1 icmp eq (double* bitcast (i32* @x to double*), double* @z) to i32)

Discovered in code which uses a static variable’s address as a failure indicator. Imagine a function which returns 0 for out of memory, &some_var for bad arguments, pointer to something useful otherwise. The static variable happens to have a different type because flexible array members are involved with length 0 for the failure indicator and length !=0 in general.

I consider this a failure in the alias analysis - would a patch be welcome, or is this intended behaviour that I’ve missed the point of?



Hi, Jon,

We don’t simplify pointer quality based on AA because an AA noalias result is not strong enough to imply pointer inequality. It certainly seems possible that our existing logic could be improved. I suspect you’ll want to look at ConstantFoldCompareInstruction, and perhaps specifically evaluateICmpRelation, in lib/IR/ConstantFold.cpp. Patches welcome.