[llvm-dev] Basic AA fail. Bug or feature?

[Hal Finkel via llvm-dev]

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>