[llvm-dev] LoopIdiomRegognize vs Preserved
Haicheng Wu via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 16 12:21:56 PST 2016
Hi Mikael,
I created a patch to fix this (http://reviews.llvm.org/D17303). Please
check.
Best,
Haicheng
-----Original Message-----
From: Mikael Holmén [mailto:mikael.holmen at ericsson.com]
Sent: Monday, February 15, 2016 5:46 AM
To: Haicheng Wu
Cc: llvm-dev at lists.llvm.org
Subject: Re: [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
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
More information about the llvm-dev
mailing list