[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



REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7451

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/