LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 25263 - LiveIn lists for MBBs are incorrect
Summary: LiveIn lists for MBBs are incorrect
Status: RESOLVED FIXED
Alias: None
Product: clang
Classification: Unclassified
Component: LLVM Codegen (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Matthias Braun
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-20 11:40 PDT by Jonas Paulsson
Modified: 2016-07-12 13:46 PDT (History)
5 users (show)

See Also:
Fixed By Commit(s):


Attachments
clang input (19.38 KB, application/octet-stream)
2015-10-20 11:40 PDT, Jonas Paulsson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Paulsson 2015-10-20 11:40:12 PDT
Created attachment 15123 [details]
clang input

The provided test case shows that the LiveIn lists for some MBB have been filled with long lists of non-live registers. This seems to happen after Control Flow Optimizer, and after If Converter. Target is SystemZ.

Test case provided. It is reduced, but still have two small functions due to inlining results required to reproduce the interesting function.

Run with:
./bin/clang -cc1 -triple s390x-ibm-linux-gnu -S -disable-free -mrelocation-model static -mthread-model posix -fmath-errno -target-cpu z13 -momit-leaf-frame-pointer -v -O3 -funroll-loops -vectorize-loops -vectorize-slp -o c-typeck.reduced.s -x ir c-typeck.reduced.bc -mllvm -print-machineinstrs >& out

The file 'out' will have the printed instructions. 
The 'build_function_call' function displays the problem.

In the fragments of the dump below, it is clear that some return-blocks or their fall-through predecessor have very long lists of live-in regs that do not belong there. This is bad because it will make later optimizations more limited - for instance those using LivePhysRegs for liveness tracking.

# After Control Flow Optimizer:

BB#114: derived from LLVM BB %cleanup
    Live Ins: %V8 %V9 %V10 %V11 %V12 %V13 %V14 %V15 %F8D %F9D %F10D %F11D %F12D %F13D %F14D %F15D %F8Q %F9Q %F12Q %F13Q %F8S %F9S %F10S %F11S %F12S %F13S %F14S %F15S %R2D %R3D %R2
H %R3H %R2L %R3L %R2Q %V8 %V9 %V10 %V11 %V12 %V13 %V14 %V15 %F8D %F9D %F10D %F11D %F12D %F13D %F14D %F15D %F8Q %F9Q %F12Q %F13Q %F8S %F9S %F10S %F11S %F12S %F13S %F14S %F15S %R2D 
%R2H %R2L %R2Q %V8 %V9 %V10 %V11 %V12 %V13 %V14 %V15 %F8D %F9D %F10D %F11D %F12D %F13D %F14D %F15D %F8Q %F9Q %F12Q %F13Q %F8S %F9S %F10S %F11S %F12S %F13S %F14S %F15S
    Predecessors according to CFG: BB#113 BB#12 BB#10
        %R2D<def> = LGRL <ga:@global_trees>; mem:LD8[getelementptr inbounds ([51 x %union.tree_node*], [51 x %union.tree_node*]* @global_trees, i64 0, i64 0)](tbaa=!3)
    Successors according to CFG: BB#115

BB#115: derived from LLVM BB %cleanup
    Live Ins: %R2D
    Predecessors according to CFG: BB#106 BB#110 BB#108 BB#112 BB#114 BB#109
        %R6D<def>, %R15D<def> = LMG %R15D, 248, %R7D<imp-def>, %R8D<imp-def>, %R9D<imp-def>, %R10D<imp-def>, %R11D<imp-def>, %R12D<imp-def>, %R13D<imp-def>, %R14D<imp-def>
        Return %R2D<imp-use>


# After If Converter:

BB#114: 
    Live Ins: %R1D %V8 %V9 %V10 %V11 %V12 %V13 %V14 %V15 %F8D %F9D %F10D %F11D %F12D %F13D %F14D %F15D %F8Q %F9Q %F12Q %F13Q %F8S %F9S %F10S %F11S %F12S %F13S %F14S %F15S %R1D %R1H %R1L %R0Q
    Predecessors according to CFG: BB#107 BB#110
        %R2D<def> = LGR %R1D<kill>
        %R6D<def>, %R15D<def> = LMG %R15D, 248, %R7D<imp-def>, %R8D<imp-def>, %R9D<imp-def>, %R10D<imp-def>, %R11D<imp-def>, %R12D<imp-def>, %R13D<imp-def>, %R14D<imp-def>
        Return %R2D<imp-use>
Comment 1 Matthias Braun 2016-07-06 19:07:46 PDT
This is probably caused by the BranchFolder adding all the pristine register as well as all subregisters. I may have accidentally fixed this here: http://reviews.llvm.org/D22027
Comment 2 Matthias Braun 2016-07-06 19:13:34 PDT
I tried confirming my guess that D22027 fixes this, but when I run the (huge) reproducer through llc I don't get any BB#114
Comment 3 Matthias Braun 2016-07-12 13:46:44 PDT
Marking this as fixed now that http://reviews.llvm.org/D22027 has landed in r275201.

I believe it to be fixed even though I cannot reproduce with the original testcase. Please verify and re-open if necessary.