[PATCH] PR17623 -- GlobalsModRef alias error fix

[Nick Lewycky]

David Callahan wrote:
> Hi chandlerc,
>
> PR17623 exposes a bug through LTO in GlobalsModRef where the notion of a global that indirectly owns memory is only true if it is not initialized to point to some other named memory. The revision filters candidate globals by this new condition.

+/// hasNullInitilaizer -- for a global variable which is non-address-taken,

(Unless it is the prevailing form in this file,) please don't repeat the 
function name in the comment. Also, it has a typo.

+  // If initilazed to the null pointer, ignore it.

Typo again.


At a high level, I have some problems with globals-mod-ref-aa. It's 
relying on LLVM IR types, which is a bad idea (consider a global union { 
intptr_t i; char *p; }). The AnalyzeGlobals function appears to be 
computing whether things have their address taken, and doesn't read nor 
write unnamed_addr.

I don't understand why you didn't add the "is null" to 
AnalyzeIndirectGlobalMemory. It seems to go with "non-aliased heap 
memory" because heap allocators can return null. If all stores to it 
store the result of malloc or a nullptr, it should be fine for it to 
detect a store internally. It looks like it tries to handle a global 
that always points to the result of malloc, but different malloc's in 
different places.

Also, do we ever have it initialized to undef? Or do we canonicalize 
those hasInitializer() == false?

Nick

>
> REPOSITORY
>    rL LLVM
>
> http://reviews.llvm.org/D7451
>
> Files:
>    lib/Analysis/IPA/GlobalsModRef.cpp
>    test/Analysis/GlobalsModRef/pr17623.ll
>
> EMAIL PREFERENCES
>    http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits