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

Fri May 27 13:56:20 PDT 2016

r271043 should take care of this problem.

-Krzysztof

On 5/27/2016 2:55 PM, Krzysztof Parzyszek via llvm-commits wrote:
> 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