Mikael Holmén via llvm-dev
2016-Feb-10 07:02 UTC
[llvm-dev] LoopIdiomRegognize vs Preserved
Hi, On 02/10/2016 01:23 AM, haicheng at codeaurora.org wrote:> Thank you, Mikael. I can reproduce what you saw and am looking into it.Great!> Just curious, why do you run loop-deletion before licm and loop-idiom?As part of our internal testing we use Csmith to generate C-programs and then we run the compiler with random generated compiler flags on that input. This bug was triggered in one of those runs, so the options to opt are not something we use in our normal pipeline, but used to find faults. /Mikael> The latter two can cause empty loops. > > Best, > > Haicheng > >> Hi Haicheng, >> >> Originally I ran into this on our out-of-tree target but I managed to >> reproduce the crash on X86 as well now: >> >> build-all/bin/opt -S -sroa -loop-rotate -loop-deletion -licm >> -loop-idiom ../llvm/bugpoint-reduced-simplified.i8+.ll >> >> gives: >> >> While deleting: void % >> An asserting value handle still pointed to this value! >> UNREACHABLE executed at ../lib/IR/Value.cpp:696! >> 0 opt 0x0000000001752bc8 >> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 >> 1 opt 0x0000000001751376 llvm::sys::RunSignalHandlers() + 54 >> 2 opt 0x00000000017537ca >> 3 libpthread.so.0 0x00007f1909a70340 >> 4 libc.so.6 0x00007f1908c98cc9 gsignal + 57 >> 5 libc.so.6 0x00007f1908c9c0d8 abort + 328 >> 6 opt 0x000000000170cddd >> llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) >> + 461 >> 7 opt 0x000000000137bd3b >> llvm::ValueHandleBase::ValueIsDeleted(llvm::Value*) + 1051 >> 8 opt 0x000000000137b5db llvm::Value::~Value() + 43 >> 9 opt 0x0000000001322319 llvm::CallInst::~CallInst() + 9 >> 10 opt 0x000000000131e676 >> llvm::Instruction::eraseFromParent() + 86 >> 11 opt 0x00000000015e8d14 >> 12 opt 0x00000000015e8630 >> 13 opt 0x00000000015e4e6a >> 14 opt 0x0000000000f5404e >> llvm::LPPassManager::runOnFunction(llvm::Function&) + 1086 >> 15 opt 0x000000000134a034 >> llvm::FPPassManager::runOnFunction(llvm::Function&) + 516 >> 16 opt 0x000000000134a27b >> llvm::FPPassManager::runOnModule(llvm::Module&) + 43 >> 17 opt 0x000000000134a757 >> llvm::legacy::PassManagerImpl::run(llvm::Module&) + 903 >> 18 opt 0x000000000062aa9e main + 8782 >> 19 libc.so.6 0x00007f1908c83ec5 __libc_start_main + 245 >> 20 opt 0x0000000000618bcf >> Stack dump: >> 0. Program arguments: build-all/bin/opt -S -sroa -loop-rotate >> -loop-deletion -licm -loop-idiom >> ../llvm/bugpoint-reduced-simplified.i8+.ll >> 1. Running pass 'Function Pass Manager' on module >> '../llvm/bugpoint-reduced-simplified.i8+.ll'. >> 2. Running pass 'Loop Pass Manager' on function '@set_array' >> 3. Running pass 'Recognize loop idioms' on basic block '%bb4' >> Abort >> >> /Mikael >> >> On 02/08/2016 05:50 PM, Haicheng Wu wrote: >>> Hi Mikael, >>> >>> What is your compilation command to trig the assert? I am trying to >>> reproduce your problem. >>> >>> Thank you, >>> >>> Haicheng >>> >>> -----Original Message----- >>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >>> Mikael Holmén via llvm-dev >>> Sent: Monday, February 08, 2016 4:33 AM >>> To: llvm-dev at lists.llvm.org >>> Subject: [llvm-dev] LoopIdiomRegognize vs Preserved >>> >>> Hi, >>> >>> I'm having problems with the LoopIdiomRegognizer crashing on me with >>> >>> An asserting value handle still pointed to this value! >>> UNREACHABLE executed at ../lib/IR/Value.cpp:695! >>> >>> If I remove >>> >>> AU.addPreserved<LoopInfoWrapperPass>(); >>> >>> or >>> >>> AU.addPreserved<AAResultsWrapperPass>(); >>> >>> everything goes well. >>> >>> The C-code triggering this is >>> >>> void foo(int a[10][10]) >>> { >>> int i, j, k; >>> >>> for (i = 0; i < 1; i++) { >>> for (j = 0; j < 2; j++) { >>> for (k = 0; k < 10; k++) { >>> a[j][k] = 42; >>> } >>> } >>> } >>> } >>> >>> First LoopIdiomRecognize replaces the store in the inner loop with a >>> memset in the outer loop, and later, when examining the outer loop it >>> tries to replace that memset with an even bigger memset in the outermost >>> loop. But then, when removing the "old" memset, the assert blows. >>> >>> I don't know LoopIdiomRecognize very well at all, is it obvious that >>> AAResultsWrapperPass and/or LoopInfoWrapperPass should not be preserved >>> here? >>> >>> Regards, >>> Mikael >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >> > > >
Hi Michael, I figure out what is going on here. If you run in the order of -loop-deletion -licm -loop-idiom, loop-deletion runs in the first function pass, licm and loop-idiom run together in the second function pass (i.e. loop-deletion processes all the three nested loops first, then licm on the inner loop, loop-idiom on the inner loop, licm on the middle loop, loop-idiom on the middle loop, ...). So, after loop-deletion, 1. In the innermost loop, licm has no optimization to do. 2. loop-idiom replaces the store of the innermost loop with a small memset in the middle loop. 3. In the middle loop, LICM adds the small memset to a AliasSetTracker. AliasSetTracker does not recognize memset and treats memset as an unknown instruction. All unknown instructions are tagged with an Asserting ValueHandle. 4. LICM assumes no other pass can modify the processed sub loop, but loop-idiom replaces the small memset in the middle loop with the large memset in the outer loop. When deleting the small memset, the Asserting ValueHandle still exists and triggers the assertion. If removing AU.addPreserved<AAResultsWrapperPass>(), licm and loop-idiom run separately and the Asserting ValueHandle can be properly handled by LICM. If you run in the normal loop pipeline (-licm -loop-idiom -loop-deletion), licm and loop-idiom are also separated. I think there are several issues here 1. loop-idiom preserves AAResults, but does not update it. 2. licm's assumption that no other loop pass interferes with licm's processed subloops is not safe. 3. AliasSetTracker treats memset as an unknown instruction. Best, Haicheng -----Original Message----- From: Mikael Holmén [mailto:mikael.holmen at ericsson.com] Sent: Wednesday, February 10, 2016 2:02 AM To: haicheng at codeaurora.org Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] LoopIdiomRegognize vs Preserved Hi, On 02/10/2016 01:23 AM, haicheng at codeaurora.org wrote:> Thank you, Mikael. I can reproduce what you saw and am looking into it.Great!> Just curious, why do you run loop-deletion before licm and loop-idiom?As part of our internal testing we use Csmith to generate C-programs and then we run the compiler with random generated compiler flags on that input. This bug was triggered in one of those runs, so the options to opt are not something we use in our normal pipeline, but used to find faults. /Mikael> The latter two can cause empty loops. > > Best, > > Haicheng > >> Hi Haicheng, >> >> Originally I ran into this on our out-of-tree target but I managed to >> reproduce the crash on X86 as well now: >> >> build-all/bin/opt -S -sroa -loop-rotate -loop-deletion -licm >> -loop-idiom ../llvm/bugpoint-reduced-simplified.i8+.ll >> >> gives: >> >> While deleting: void % >> An asserting value handle still pointed to this value! >> UNREACHABLE executed at ../lib/IR/Value.cpp:696! >> 0 opt 0x0000000001752bc8 >> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 >> 1 opt 0x0000000001751376 llvm::sys::RunSignalHandlers() + 54 >> 2 opt 0x00000000017537ca >> 3 libpthread.so.0 0x00007f1909a70340 >> 4 libc.so.6 0x00007f1908c98cc9 gsignal + 57 >> 5 libc.so.6 0x00007f1908c9c0d8 abort + 328 >> 6 opt 0x000000000170cddd >> llvm::llvm_unreachable_internal(char const*, char const*, unsigned >> int) >> + 461 >> 7 opt 0x000000000137bd3b >> llvm::ValueHandleBase::ValueIsDeleted(llvm::Value*) + 1051 >> 8 opt 0x000000000137b5db llvm::Value::~Value() + 43 >> 9 opt 0x0000000001322319 llvm::CallInst::~CallInst() + 9 >> 10 opt 0x000000000131e676 >> llvm::Instruction::eraseFromParent() + 86 >> 11 opt 0x00000000015e8d14 >> 12 opt 0x00000000015e8630 >> 13 opt 0x00000000015e4e6a >> 14 opt 0x0000000000f5404e >> llvm::LPPassManager::runOnFunction(llvm::Function&) + 1086 >> 15 opt 0x000000000134a034 >> llvm::FPPassManager::runOnFunction(llvm::Function&) + 516 >> 16 opt 0x000000000134a27b >> llvm::FPPassManager::runOnModule(llvm::Module&) + 43 >> 17 opt 0x000000000134a757 >> llvm::legacy::PassManagerImpl::run(llvm::Module&) + 903 >> 18 opt 0x000000000062aa9e main + 8782 >> 19 libc.so.6 0x00007f1908c83ec5 __libc_start_main + 245 >> 20 opt 0x0000000000618bcf >> Stack dump: >> 0. Program arguments: build-all/bin/opt -S -sroa -loop-rotate >> -loop-deletion -licm -loop-idiom >> ../llvm/bugpoint-reduced-simplified.i8+.ll >> 1. Running pass 'Function Pass Manager' on module >> '../llvm/bugpoint-reduced-simplified.i8+.ll'. >> 2. Running pass 'Loop Pass Manager' on function '@set_array' >> 3. Running pass 'Recognize loop idioms' on basic block '%bb4' >> Abort >> >> /Mikael >> >> On 02/08/2016 05:50 PM, Haicheng Wu wrote: >>> Hi Mikael, >>> >>> What is your compilation command to trig the assert? I am trying to >>> reproduce your problem. >>> >>> Thank you, >>> >>> Haicheng >>> >>> -----Original Message----- >>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >>> Mikael Holmén via llvm-dev >>> Sent: Monday, February 08, 2016 4:33 AM >>> To: llvm-dev at lists.llvm.org >>> Subject: [llvm-dev] LoopIdiomRegognize vs Preserved >>> >>> Hi, >>> >>> I'm having problems with the LoopIdiomRegognizer crashing on me with >>> >>> An asserting value handle still pointed to this value! >>> UNREACHABLE executed at ../lib/IR/Value.cpp:695! >>> >>> If I remove >>> >>> AU.addPreserved<LoopInfoWrapperPass>(); >>> >>> or >>> >>> AU.addPreserved<AAResultsWrapperPass>(); >>> >>> everything goes well. >>> >>> The C-code triggering this is >>> >>> void foo(int a[10][10]) >>> { >>> int i, j, k; >>> >>> for (i = 0; i < 1; i++) { >>> for (j = 0; j < 2; j++) { >>> for (k = 0; k < 10; k++) { >>> a[j][k] = 42; >>> } >>> } >>> } >>> } >>> >>> First LoopIdiomRecognize replaces the store in the inner loop with a >>> memset in the outer loop, and later, when examining the outer loop >>> it tries to replace that memset with an even bigger memset in the >>> outermost loop. But then, when removing the "old" memset, the assertblows.>>> >>> I don't know LoopIdiomRecognize very well at all, is it obvious that >>> AAResultsWrapperPass and/or LoopInfoWrapperPass should not be >>> preserved here? >>> >>> Regards, >>> Mikael >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >> > > >
Mikael Holmén via llvm-dev
2016-Feb-15 10:45 UTC
[llvm-dev] LoopIdiomRegognize vs Preserved
Hi Haicheng, Thanks for the analysis! So what do we do with this? Should I write a bug report and fill in what we know about the problem? Thanks, Mikael On 02/11/2016 05:54 PM, Haicheng Wu wrote:> Hi Michael, > > I figure out what is going on here. If you run in the order of > -loop-deletion -licm -loop-idiom, loop-deletion runs in the first function > pass, licm and loop-idiom run together in the second function pass (i.e. > loop-deletion processes all the three nested loops first, then licm on the > inner loop, loop-idiom on the inner loop, licm on the middle loop, > loop-idiom on the middle loop, ...). So, after loop-deletion, > > 1. In the innermost loop, licm has no optimization to do. > > 2. loop-idiom replaces the store of the innermost loop with a small memset > in the middle loop. > > 3. In the middle loop, LICM adds the small memset to a AliasSetTracker. > AliasSetTracker does not recognize memset and treats memset as an unknown > instruction. All unknown instructions are tagged with an Asserting > ValueHandle. > > 4. LICM assumes no other pass can modify the processed sub loop, but > loop-idiom replaces the small memset in the middle loop with the large > memset in the outer loop. When deleting the small memset, the Asserting > ValueHandle still exists and triggers the assertion. > > If removing AU.addPreserved<AAResultsWrapperPass>(), licm and loop-idiom run > separately and the Asserting ValueHandle can be properly handled by LICM. > If you run in the normal loop pipeline (-licm -loop-idiom -loop-deletion), > licm and loop-idiom are also separated. > > I think there are several issues here > > 1. loop-idiom preserves AAResults, but does not update it. > 2. licm's assumption that no other loop pass interferes with licm's > processed subloops is not safe. > 3. AliasSetTracker treats memset as an unknown instruction. > > Best, > > Haicheng > > -----Original Message----- > From: Mikael Holmén [mailto:mikael.holmen at ericsson.com] > Sent: Wednesday, February 10, 2016 2:02 AM > To: haicheng at codeaurora.org > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] LoopIdiomRegognize vs Preserved > > Hi, > > On 02/10/2016 01:23 AM, haicheng at codeaurora.org wrote: >> Thank you, Mikael. I can reproduce what you saw and am looking into it. > > Great! > >> Just curious, why do you run loop-deletion before licm and loop-idiom? > > As part of our internal testing we use Csmith to generate C-programs and > then we run the compiler with random generated compiler flags on that input. > > This bug was triggered in one of those runs, so the options to opt are not > something we use in our normal pipeline, but used to find faults. > > /Mikael > >> The latter two can cause empty loops. >> >> Best, >> >> Haicheng >> >>> Hi Haicheng, >>> >>> Originally I ran into this on our out-of-tree target but I managed to >>> reproduce the crash on X86 as well now: >>> >>> build-all/bin/opt -S -sroa -loop-rotate -loop-deletion -licm >>> -loop-idiom ../llvm/bugpoint-reduced-simplified.i8+.ll >>> >>> gives: >>> >>> While deleting: void % >>> An asserting value handle still pointed to this value! >>> UNREACHABLE executed at ../lib/IR/Value.cpp:696! >>> 0 opt 0x0000000001752bc8 >>> llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 >>> 1 opt 0x0000000001751376 llvm::sys::RunSignalHandlers() + 54 >>> 2 opt 0x00000000017537ca >>> 3 libpthread.so.0 0x00007f1909a70340 >>> 4 libc.so.6 0x00007f1908c98cc9 gsignal + 57 >>> 5 libc.so.6 0x00007f1908c9c0d8 abort + 328 >>> 6 opt 0x000000000170cddd >>> llvm::llvm_unreachable_internal(char const*, char const*, unsigned >>> int) >>> + 461 >>> 7 opt 0x000000000137bd3b >>> llvm::ValueHandleBase::ValueIsDeleted(llvm::Value*) + 1051 >>> 8 opt 0x000000000137b5db llvm::Value::~Value() + 43 >>> 9 opt 0x0000000001322319 llvm::CallInst::~CallInst() + 9 >>> 10 opt 0x000000000131e676 >>> llvm::Instruction::eraseFromParent() + 86 >>> 11 opt 0x00000000015e8d14 >>> 12 opt 0x00000000015e8630 >>> 13 opt 0x00000000015e4e6a >>> 14 opt 0x0000000000f5404e >>> llvm::LPPassManager::runOnFunction(llvm::Function&) + 1086 >>> 15 opt 0x000000000134a034 >>> llvm::FPPassManager::runOnFunction(llvm::Function&) + 516 >>> 16 opt 0x000000000134a27b >>> llvm::FPPassManager::runOnModule(llvm::Module&) + 43 >>> 17 opt 0x000000000134a757 >>> llvm::legacy::PassManagerImpl::run(llvm::Module&) + 903 >>> 18 opt 0x000000000062aa9e main + 8782 >>> 19 libc.so.6 0x00007f1908c83ec5 __libc_start_main + 245 >>> 20 opt 0x0000000000618bcf >>> Stack dump: >>> 0. Program arguments: build-all/bin/opt -S -sroa -loop-rotate >>> -loop-deletion -licm -loop-idiom >>> ../llvm/bugpoint-reduced-simplified.i8+.ll >>> 1. Running pass 'Function Pass Manager' on module >>> '../llvm/bugpoint-reduced-simplified.i8+.ll'. >>> 2. Running pass 'Loop Pass Manager' on function '@set_array' >>> 3. Running pass 'Recognize loop idioms' on basic block '%bb4' >>> Abort >>> >>> /Mikael >>> >>> On 02/08/2016 05:50 PM, Haicheng Wu wrote: >>>> Hi Mikael, >>>> >>>> What is your compilation command to trig the assert? I am trying to >>>> reproduce your problem. >>>> >>>> Thank you, >>>> >>>> Haicheng >>>> >>>> -----Original Message----- >>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >>>> Mikael Holmén via llvm-dev >>>> Sent: Monday, February 08, 2016 4:33 AM >>>> To: llvm-dev at lists.llvm.org >>>> Subject: [llvm-dev] LoopIdiomRegognize vs Preserved >>>> >>>> Hi, >>>> >>>> I'm having problems with the LoopIdiomRegognizer crashing on me with >>>> >>>> An asserting value handle still pointed to this value! >>>> UNREACHABLE executed at ../lib/IR/Value.cpp:695! >>>> >>>> If I remove >>>> >>>> AU.addPreserved<LoopInfoWrapperPass>(); >>>> >>>> or >>>> >>>> AU.addPreserved<AAResultsWrapperPass>(); >>>> >>>> everything goes well. >>>> >>>> The C-code triggering this is >>>> >>>> void foo(int a[10][10]) >>>> { >>>> int i, j, k; >>>> >>>> for (i = 0; i < 1; i++) { >>>> for (j = 0; j < 2; j++) { >>>> for (k = 0; k < 10; k++) { >>>> a[j][k] = 42; >>>> } >>>> } >>>> } >>>> } >>>> >>>> First LoopIdiomRecognize replaces the store in the inner loop with a >>>> memset in the outer loop, and later, when examining the outer loop >>>> it tries to replace that memset with an even bigger memset in the >>>> outermost loop. But then, when removing the "old" memset, the assert > blows. >>>> >>>> I don't know LoopIdiomRecognize very well at all, is it obvious that >>>> AAResultsWrapperPass and/or LoopInfoWrapperPass should not be >>>> preserved here? >>>> >>>> Regards, >>>> Mikael >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> >>> >> >> >> > > >