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 43859 - check_cfc: dash g generate different code with phi-node-elimination
Summary: check_cfc: dash g generate different code with phi-node-elimination
Status: NEW
Alias: None
Product: libraries
Classification: Unclassified
Component: Common Code Generator Code (show other bugs)
Version: trunk
Hardware: PC Linux
: P enhancement
Assignee: Chris Ye
URL:
Keywords:
Depends on:
Blocks: 37728
  Show dependency tree
 
Reported: 2019-10-31 05:21 PDT by Chris Ye
Modified: 2020-03-19 08:42 PDT (History)
4 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Ye 2019-10-31 05:21:15 PDT
Debug Info should have no effect on codegen, using check_cfc to scan llvm_test_suite, find a bug here: 

Reproduce:
----------------------------------------------------------------------
$HOME/llvm-project/clang/utils/check_cfc/clang++ -w -c -O1 $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP/7zip/Archive/SwfHandler.cpp -o tmp.ll -I $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP/myWindows -I $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP -I $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP/include_windows

[result]
Check CFC, checking: dash_g_no_change, dash_s_no_change
/home/chris/test-suite/MultiSource/Benchmarks/7zip/CPP/7zip/Archive/SwfHandler.cpp Code difference detected with -g
--- /tmp/tmpGFtFSg.o

+++ /tmp/tmpBtaqgK.o

@@ -522,6 +522,6 @@

  647:	41 54                	push   %r12
  649:	53                   	push   %rbx
  64a:	48 83 ec 58          	sub    $0x58,%rsp
- 64e:	4c 89 44 24 10       	mov    %r8,0x10(%rsp)
- 653:	89 4c 24 18          	mov    %ecx,0x18(%rsp)
+ 64e:	4c 89 44 24 08       	mov    %r8,0x8(%rsp)
+ 653:	89 4c 24 10          	mov    %ecx,0x10(%rsp)
  657:	41 89 d6             	mov    %edx,%r14d
*** Diff truncated ***
----------------------------------------------------------------------


Reduce reproduce:
----------------------------------------------------------------------
clang++ -S -O1 -mllvm -opt-bisect-limit=5449 $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP/7zip/Archive/SwfHandler.cpp -I $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP/myWindows -I $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP -I $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP/include_windows -o out1.s 2>log1
clang++ -g -S -O1 -mllvm -opt-bisect-limit=5453 $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP/7zip/Archive/SwfHandler.cpp -I $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP/myWindows -I $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP -I $HOME/test-suite/MultiSource/Benchmarks/7zip/CPP/include_windows -o out2.s 2>log2

[result]
out1.s:
    1593         movq    %r8, 16(%rsp)           # 8-byte Spill
    1594         movl    %ecx, 24(%rsp)          # 4-byte Spill
out2.s:
    2745         movq    %r8, 8(%rsp)            # 8-byte Spill
    2748         movl    %ecx, 16(%rsp)          # 4-byte Spill
log1:
    BISECT: running pass (5449) Stack Slot Coloring on function
log2:
    BISECT: running pass (5453) Stack Slot Coloring on function
Comment 1 Chris Ye 2019-10-31 05:34:21 PDT
For quick debug, the difference occurred in function StackSlotColoring::RewriteInstruction (lib/CodeGen/StackSlotColoring.cpp)

looks like the frame index is impacted while handling debug instruction. 

SlotMapping[OldFI] got the different NewFI.
Without debug the NewFI is 7, bug with debug the NewFI is 6

MOV32mr %stack.7, 1, $noreg, 0, $noreg, $ecx :: (store 4 into %stack.7)
MOV32mr %stack.6, 1, $noreg, 0, $noreg, $ecx :: (store 4 into %stack.6)
Comment 2 Chris Ye 2019-11-06 18:02:57 PST
Is there a better way to find the implemented pass between two series pass? 
  1. BISECT: running pass (5452) Machine Instruction Scheduler
  2. BISECT: running pass (5453) Stack Slot Coloring

I have found the MBB changing while run Stack Slot Coloring pass and its depended pass, I have printed the MBBs at the beginning of Stack Slot Coloring, they are already changed. but at the end of 5452, they are the same(with/without -g). So I guess the difference is made by StackSlotColor's dependences.

from the INITIALIZE_PASS_DEPENDENCY, I have checked 
SlotIndexes, LiveStacks, MachineLoopInfo, MachineDominatorTree.

With debug below passes: InlineSplier, RegAllocGreedy have also been implemented. I have found some changes but not find the root cause. I think there is some pass missed that I want to find out and debug.

Appreciate if someone could give some suggest about howto check all the pass which be implemented between two series pass (5452 and 5453), or is there a way (--option?) to print out all LLVM_DEBUG log by clang++ command (already with -DCMAKE_BUILD_TYPE=Debug build).
Comment 3 Paul Robinson 2019-11-07 07:17:12 PST
(In reply to Chris Ye from comment #2)
> Appreciate if someone could give some suggest about howto check all the pass
> which be implemented between two series pass (5452 and 5453), or is there a
> way (--option?) to print out all LLVM_DEBUG log by clang++ command (already
> with -DCMAKE_BUILD_TYPE=Debug build).

There are options that enable the logging done by LLVM_DEBUG.
The `-debug` option turns on all LLVM_DEBUG logging.
The `-debug-only=foo` option turns on logging for modules that define the
preprocessor symbol DEBUG_TYPE to "foo".  The argument to -debug-only can
be a comma-separated list, so `-debug-only=foo,bar` will enable logging
for modules "foo" and "bar".

Passes usually define DEBUG_TYPE to something sensible, but you'll want to
look at passes of interest to make sure you spell their DEBUG_TYPE correctly.

Another tactic would be to generate IR from clang, and then use the 'opt'
(for the middle-end) or 'llc' (for the back-end) to isolate passes.  These
tools provide options that cause passes to dump the IR/MIR before or after 
they run.
To generate IR from Clang, use `clang -emit-llvm -S -disable-llvm-passes`
which should produce a .ll file containing the initial IR in textual form.
Then you can run that IR through `opt` or `llc` with the various print 
options: 
--print-after=foo
--print-after-all
--print-before=foo
--print-before-all

The "after" options print the IR/MIR before the pass runs, the "before"
options print it before the pass runs. "foo" specifies one or more passes,
and can be a comma-separated list.
Note, I am not sure the pass names for the --print options are the same as
the ones used for -debug-only.  I think they often are but this is not
guaranteed.
Comment 4 Chris Ye 2019-11-21 06:04:07 PST
Hi Robinson, thanks for the help. It really help me to find the root cause more quickly. 

I have found this issue cased by phi-node-elimination pass (llvm/lib/CodeGen/PHIElimination.cpp)

In the function PHIElimination::EliminatePHINodes (https://github.com/llvm/llvm-project/blob/7b957ddc981d65276ca5aa0e7208890269cc9682/llvm/lib/CodeGen/PHIElimination.cpp#L211)

When there is dbg instruction after the beginning PHI instruction, and Label next to dbg.value. It will get different LastPHIIt with debug.value by func ()
> MachineBasicBlock::iterator LastPHIIt =  
>    std::prev(MBB.SkipPHIsAndLabels(MBB.begin()));
and fail to lower PHI instruction. the case simplify as below:

-----------------
PHI
dbg.value
LABEL
-----------------

we could use SkipPHIsLabelsAndDebug instead of SkipPHIsAndLabels to skip debug when finding forward, and also skip debug when find backward by std::prev() if there is dbg.value after LABEL.I'll try to fix this issue.
Comment 5 Chris Ye 2019-11-22 05:52:34 PST
patch to fix this issue: https://reviews.llvm.org/D70597