[llvm-dev] LoopIdiomRegognize vs Preserved

[via llvm-dev]

Thank you, Mikael.  I can reproduce what you saw and am looking into it. 
Just curious, why do you run loop-deletion before licm and loop-idiom? 
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
>>
>>
>