[llvm] r270885 - Do not rename registers that do not start an independent live range

Krzysztof Parzyszek via llvm-commits llvm-commits at lists.llvm.org
Fri May 27 12:55:22 PDT 2016


Interesting...

I'm building it now. Hopefully it's an easy fix.

-Krzysztof

On 5/27/2016 2:49 PM, Evgenii Stepanov wrote:
> Here it is:
> ==91258==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 136 byte(s) in 1 object(s) allocated from:
>     #0 0x71ab0b in operator new(unsigned long)
> /code/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:78:35
>     #1 0x14736b3 in llvm::createHexagonExpandCondsets()
> /code/llvm/lib/Target/Hexagon/HexagonExpandCondsets.cpp:1365:10
>     #2 0x1390077 in HexagonPassConfig
> /code/llvm/lib/Target/Hexagon/HexagonTargetMachine.cpp:202:21
>     #3 0x1390077 in
> llvm::HexagonTargetMachine::createPassConfig(llvm::legacy::PassManagerBase&)
> /code/llvm/lib/Target/Hexagon/HexagonTargetMachine.cpp:227
>     #4 0x72fac3 in compileModule(char**, llvm::LLVMContext&)
> /code/llvm/tools/llc/llc.cpp:400:38
>     #5 0x72b7ba in main /code/llvm/tools/llc/llc.cpp:244:22
>     #6 0x7efe1dedeec4 in __libc_start_main
> /build/eglibc-3GlaMS/eglibc-2.19/csu/libc-start.c:287
>
> Indirect leak of 8 byte(s) in 1 object(s) allocated from:
>     #0 0x6ee1dd in __interceptor_malloc
> /code/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64:3
>     #1 0x147376b in BitVector /code/llvm/include/llvm/ADT/BitVector.h:86:23
>     #2 0x147376b in MachineFunctionProperties
> /code/llvm/include/llvm/CodeGen/MachineFunction.h:157
>     #3 0x147376b in MachineFunctionPass
> /code/llvm/include/llvm/CodeGen/MachineFunctionPass.h:42
>     #4 0x147376b in HexagonExpandCondsets
> /code/llvm/lib/Target/Hexagon/HexagonExpandCondsets.cpp:96
>     #5 0x147376b in llvm::createHexagonExpandCondsets()
> /code/llvm/lib/Target/Hexagon/HexagonExpandCondsets.cpp:1365
>     #6 0x1390077 in HexagonPassConfig
> /code/llvm/lib/Target/Hexagon/HexagonTargetMachine.cpp:202:21
>     #7 0x1390077 in
> llvm::HexagonTargetMachine::createPassConfig(llvm::legacy::PassManagerBase&)
> /code/llvm/lib/Target/Hexagon/HexagonTargetMachine.cpp:227
>     #8 0x72fac3 in compileModule(char**, llvm::LLVMContext&)
> /code/llvm/tools/llc/llc.cpp:400:38
>     #9 0x72b7ba in main /code/llvm/tools/llc/llc.cpp:244:22
>     #10 0x7efe1dedeec4 in __libc_start_main
> /build/eglibc-3GlaMS/eglibc-2.19/csu/libc-start.c:287
>
> Indirect leak of 8 byte(s) in 1 object(s) allocated from:
>     #0 0x6ee1dd in __interceptor_malloc
> /code/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64:3
>     #1 0x14737eb in BitVector /code/llvm/include/llvm/ADT/BitVector.h:86:23
>     #2 0x14737eb in MachineFunctionProperties
> /code/llvm/include/llvm/CodeGen/MachineFunction.h:157
>     #3 0x14737eb in MachineFunctionPass
> /code/llvm/include/llvm/CodeGen/MachineFunctionPass.h:42
>     #4 0x14737eb in HexagonExpandCondsets
> /code/llvm/lib/Target/Hexagon/HexagonExpandCondsets.cpp:96
>     #5 0x14737eb in llvm::createHexagonExpandCondsets()
> /code/llvm/lib/Target/Hexagon/HexagonExpandCondsets.cpp:1365
>     #6 0x1390077 in HexagonPassConfig
> /code/llvm/lib/Target/Hexagon/HexagonTargetMachine.cpp:202:21
>     #7 0x1390077 in
> llvm::HexagonTargetMachine::createPassConfig(llvm::legacy::PassManagerBase&)
> /code/llvm/lib/Target/Hexagon/HexagonTargetMachine.cpp:227
>     #8 0x72fac3 in compileModule(char**, llvm::LLVMContext&)
> /code/llvm/tools/llc/llc.cpp:400:38
>     #9 0x72b7ba in main /code/llvm/tools/llc/llc.cpp:244:22
>     #10 0x7efe1dedeec4 in __libc_start_main
> /build/eglibc-3GlaMS/eglibc-2.19/csu/libc-start.c:287
>
> Indirect leak of 8 byte(s) in 1 object(s) allocated from:
>     #0 0x6ee1dd in __interceptor_malloc
> /code/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64:3
>     #1 0x147386b in BitVector /code/llvm/include/llvm/ADT/BitVector.h:86:23
>     #2 0x147386b in MachineFunctionProperties
> /code/llvm/include/llvm/CodeGen/MachineFunction.h:157
>     #3 0x147386b in MachineFunctionPass
> /code/llvm/include/llvm/CodeGen/MachineFunctionPass.h:42
>     #4 0x147386b in HexagonExpandCondsets
> /code/llvm/lib/Target/Hexagon/HexagonExpandCondsets.cpp:96
>     #5 0x147386b in llvm::createHexagonExpandCondsets()
> /code/llvm/lib/Target/Hexagon/HexagonExpandCondsets.cpp:1365
>     #6 0x1390077 in HexagonPassConfig
> /code/llvm/lib/Target/Hexagon/HexagonTargetMachine.cpp:202:21
>     #7 0x1390077 in
> llvm::HexagonTargetMachine::createPassConfig(llvm::legacy::PassManagerBase&)
> /code/llvm/lib/Target/Hexagon/HexagonTargetMachine.cpp:227
>     #8 0x72fac3 in compileModule(char**, llvm::LLVMContext&)
> /code/llvm/tools/llc/llc.cpp:400:38
>     #9 0x72b7ba in main /code/llvm/tools/llc/llc.cpp:244:22
>     #10 0x7efe1dedeec4 in __libc_start_main
> /build/eglibc-3GlaMS/eglibc-2.19/csu/libc-start.c:287
>
> On Fri, May 27, 2016 at 11:54 AM, Evgenii Stepanov
> <eugeni.stepanov at gmail.com> wrote:
>> It should be enough to build llvm with -DLLVM_USE_SANITIZER=Address
>> and run check-llvm. The bot also links LLVM with ASan-instrumented
>> libc++, but that probably would not be necessary.
>>
>>
>> On Fri, May 27, 2016 at 11:48 AM, Krzysztof Parzyszek
>> <kparzysz at codeaurora.org> wrote:
>>> Hi,
>>> It doesn't show why it fails, there is only "Exit Code: 1".  Do you have
>>> steps to reproduce this problem?
>>>
>>> -Krzysztof
>>>
>>>
>>>
>>> On 5/27/2016 1:15 PM, Evgenii Stepanov wrote:
>>>>
>>>> Hi,
>>>>
>>>> this test is failing on ASan:
>>>>
>>>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11794/steps/check-llvm%20asan/logs/stdio
>>>>
>>>> On Thu, May 26, 2016 at 11:22 AM, Krzysztof Parzyszek via llvm-commits
>>>> <llvm-commits at lists.llvm.org> wrote:
>>>>>
>>>>> Author: kparzysz
>>>>> Date: Thu May 26 13:22:53 2016
>>>>> New Revision: 270885
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=270885&view=rev
>>>>> Log:
>>>>> Do not rename registers that do not start an independent live range
>>>>>
>>>>> Added:
>>>>>     llvm/trunk/test/CodeGen/MIR/Hexagon/
>>>>>     llvm/trunk/test/CodeGen/MIR/Hexagon/anti-dep-partial.mir
>>>>> Modified:
>>>>>     llvm/trunk/lib/CodeGen/AggressiveAntiDepBreaker.cpp
>>>>>
>>>>> Modified: llvm/trunk/lib/CodeGen/AggressiveAntiDepBreaker.cpp
>>>>> URL:
>>>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/AggressiveAntiDepBreaker.cpp?rev=270885&r1=270884&r2=270885&view=diff
>>>>>
>>>>> ==============================================================================
>>>>> --- llvm/trunk/lib/CodeGen/AggressiveAntiDepBreaker.cpp (original)
>>>>> +++ llvm/trunk/lib/CodeGen/AggressiveAntiDepBreaker.cpp Thu May 26
>>>>> 13:22:53 2016
>>>>> @@ -787,6 +787,8 @@ unsigned AggressiveAntiDepBreaker::Break
>>>>>    DEBUG(dbgs() << '\n');
>>>>>  #endif
>>>>>
>>>>> +  BitVector RegAliases(TRI->getNumRegs());
>>>>> +
>>>>>    // Attempt to break anti-dependence edges. Walk the instructions
>>>>>    // from the bottom up, tracking information about liveness as we go
>>>>>    // to help determine which registers are available.
>>>>> @@ -898,6 +900,29 @@ unsigned AggressiveAntiDepBreaker::Break
>>>>>            }
>>>>>
>>>>>            if (AntiDepReg == 0) continue;
>>>>> +
>>>>> +          // If the definition of the anti-dependency register does not
>>>>> start
>>>>> +          // a new live range, bail out. This can happen if the anti-dep
>>>>> +          // register is a sub-register of another register whose live
>>>>> range
>>>>> +          // spans over PathSU. In such case, PathSU defines only a part
>>>>> of
>>>>> +          // the larger register.
>>>>> +          RegAliases.reset();
>>>>> +          for (MCRegAliasIterator AI(AntiDepReg, TRI, true);
>>>>> AI.isValid(); ++AI)
>>>>> +            RegAliases.set(*AI);
>>>>> +          for (SDep S : PathSU->Succs) {
>>>>> +            SDep::Kind K = S.getKind();
>>>>> +            if (K != SDep::Data && K != SDep::Output && K != SDep::Anti)
>>>>> +              continue;
>>>>> +            unsigned R = S.getReg();
>>>>> +            if (!RegAliases[R])
>>>>> +              continue;
>>>>> +            if (R == AntiDepReg || TRI->isSubRegister(AntiDepReg, R))
>>>>> +              continue;
>>>>> +            AntiDepReg = 0;
>>>>> +            break;
>>>>> +          }
>>>>> +
>>>>> +          if (AntiDepReg == 0) continue;
>>>>>          }
>>>>>
>>>>>          assert(AntiDepReg != 0);
>>>>>
>>>>> Added: llvm/trunk/test/CodeGen/MIR/Hexagon/anti-dep-partial.mir
>>>>> URL:
>>>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/MIR/Hexagon/anti-dep-partial.mir?rev=270885&view=auto
>>>>>
>>>>> ==============================================================================
>>>>> --- llvm/trunk/test/CodeGen/MIR/Hexagon/anti-dep-partial.mir (added)
>>>>> +++ llvm/trunk/test/CodeGen/MIR/Hexagon/anti-dep-partial.mir Thu May 26
>>>>> 13:22:53 2016
>>>>> @@ -0,0 +1,35 @@
>>>>> +# RUN: llc -march=hexagon -post-RA-scheduler -run-pass post-RA-sched %s
>>>>> 2>&1 -o /dev/null | FileCheck %s
>>>>> +
>>>>> +--- |
>>>>> +  declare void @check(i64, i32, i32, i64)
>>>>> +  define void @foo() {
>>>>> +    ret void
>>>>> +  }
>>>>> +...
>>>>> +
>>>>> +---
>>>>> +name: foo
>>>>> +tracksRegLiveness: true
>>>>> +allVRegsAllocated: true
>>>>> +body: |
>>>>> +  bb.0:
>>>>> +    successors:
>>>>> +    liveins: %r0, %r1, %d1, %d2, %r16, %r17, %r19, %r22, %r23
>>>>> +        %r2 = A2_add %r23, killed %r17
>>>>> +        %r6 = M2_mpyi %r16, %r16
>>>>> +        %r22 = M2_accii %r22, killed %r2, 2
>>>>> +        %r7 = A2_tfrsi 12345678
>>>>> +        %r3 = A2_tfr killed %r16
>>>>> +        %d2 = A2_tfrp killed %d0
>>>>> +        %r2 = L2_loadri_io %r29, 28
>>>>> +        %r2 = M2_mpyi killed %r6, killed %r2
>>>>> +        %r23 = S2_asr_i_r %r22, 31
>>>>> +        S2_storeri_io killed %r29, 0, killed %r7
>>>>> +        ; The anti-dependency on r23 between the first A2_add and the
>>>>> +        ; S2_asr_i_r was causing d11 to be renamed, while r22 remained
>>>>> +        ; unchanged. Check that the renaming of d11 does not happen.
>>>>> +        ; CHECK: d11
>>>>> +        %d0 = A2_tfrp killed %d11
>>>>> +        J2_call @check, implicit-def %d0, implicit-def %d1, implicit-def
>>>>> %d2, implicit %d0, implicit %d1, implicit %d2
>>>>> +...
>>>>> +
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>
>>>
>>>
>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
>>> The Linux Foundation


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation


More information about the llvm-commits mailing list