GVN doesn't register new PHI nodes with AliasAnalysis

[nlewycky]

Bugzilla Link	2032
Resolution	FIXED
Resolved on	Feb 14, 2008 01:16
Version	trunk
OS	Linux
Attachments	testcase

Extended Description

This small testcase fails with -anders-aa:

$ opt -anders-aa -gvn b.bc

    %tmp27.rle = phi float* [ null, %bb ], [ %sx, %entry ]          ; <float*> [#uses=1]

opt: Andersens.cpp:497: unsigned int::Andersens::getNode(llvm::Value*): Assertion `0 && "Value does not have a node in the points-to graph!"' failed.
[New Thread 0xf7c596c0 (LWP 21274)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xf7c596c0 (LWP 21274)]
0xffffe405 in __kernel_vsyscall ()
(gdb) bt
#​0 0xffffe405 in __kernel_vsyscall ()
#​1 0xf7c85f15 in raise () from /lib/i686/cmov/libc.so.6
#​2 0xf7c87891 in abort () from /lib/i686/cmov/libc.so.6
#​3 0xf7c7f0ee in __assert_fail () from /lib/i686/cmov/libc.so.6
#​4 0x0848bc4e in getNode (this=0x86eac38, V=0x86f47a0) at Andersens.cpp:497
#​5 0x084909cc in alias (this=0x86eac38, V1=0x86f47a0, V1Size=4, V2=0x86eaf90,
V2Size=4) at Andersens.cpp:609
#​6 0x084cdccc in llvm::MemoryDependenceAnalysis::getDependency (
this=0x86e93f8, query=0x86ea960, start=0x0, block=0x86eaec8)
at MemoryDependenceAnalysis.cpp:431
#​7 0x084cdf5d in llvm::MemoryDependenceAnalysis::nonLocalHelper (
this=0x86e93f8, query=0x86ea960, block=0x86eaf18, resp=@0xffc376d4)
at MemoryDependenceAnalysis.cpp:201
#​8 0x084ce473 in llvm::MemoryDependenceAnalysis::getNonLocalDependency (
this=0x86e93f8, query=0x86ea960, resp=@0xffc376d4)
at MemoryDependenceAnalysis.cpp:288
#​9 0x0837adfe in processNonLocalLoad (this=0x86e9378, L=0x86ea960,
toErase=@0xffc378a0) at GVN.cpp:894
#​10 0x0837b2ec in processLoad (this=0x86e9378, L=0x86ea960,
lastLoad=@0xffc378d4, toErase=@0xffc378a0) at GVN.cpp:966
#​11 0x0837b611 in processInstruction (this=0x86e9378, I=0x86ea960,
currAvail=@0x86eeb34, lastSeenLoad=@0xffc378d4, toErase=@0xffc378a0)
at GVN.cpp:1129
#​12 0x0837baf2 in iterateOnFunction (this=0x86e9378, F=@0x86eb300)
at GVN.cpp:1233
#​13 0x0837bc2e in runOnFunction (this=0x86e9378, F=@0x86eb300) at GVN.cpp:1195
#​14 0x0858b582 in llvm::FPPassManager::runOnFunction (this=0x86e9140,
F=@0x86eb300) at PassManager.cpp:1184
#​15 0x0858b724 in llvm::FPPassManager::runOnModule (this=0x86e9140,
M=@0x86e8ff8) at PassManager.cpp:1204
#​16 0x0858b258 in llvm::MPPassManager::runOnModule (this=0x86e9ae0,
M=@0x86e8ff8) at PassManager.cpp:1254
#​17 0x0858b410 in llvm::PassManagerImpl::run (this=0x86eab48, M=@0x86e8ff8)
at PassManager.cpp:1328
#​18 0x0858b462 in llvm::PassManager::run (this=0xffc37af8, M=@0x86e8ff8)
at PassManager.cpp:1360
#​19 0x082edf87 in main (argc=4, argv=0xffc37cf4) at opt.cpp:430

Testcase attached.

[nlewycky]

This is a GVN bug.

[nlewycky]

proposed fix

[llvmbot]

Looks good offhand.

[nlewycky]

Fixed. Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080211/058293.html