llvm dev - Jun 2017 - 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?

Cheers

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170621/032c1610/attachment.html>

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.

  -Hal

On 06/20/2017 06:33 PM, Jon Chesterfield via llvm-dev
wrote:
> 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?
>
> Cheers
>
> Jon
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170620/264276a2/attachment-0001.html>