llvm dev - Sep 2013 - [LLVMdev] How basic block layout is determined during scheduling?

Hi, guys,

I compiled a subroutine with -O2, and llvm backend produced codes like:

##################################################################
LBB0_32:
    ...
    R31 = -1
    R20 = R31 * R20;
    ....
    bnz  R2, LBB0_34
LBB0_31:
    ...
    b  LBB0_34
LBB0_33:                  # weird basic block?
    R20 = R5
LBB0_34:
    ....
##################################################################

Wrong answer is produced when executing bove codes. LBB0_33 is not used as
destination basic block for any branch instruction, so its a dead basic
block. Original C source codes need "R20 = R5" to restore its old
value if
"bnz  R2, LBB0_34" does not change control flow.

So if I move LBB0_33 just after LBB0_32 as follows:

##################################################################
LBB0_32:
    ...
    R31 = -1
    R20 = R31 * R20;
    ....
    bnz  R2, LBB0_34

LBB0_33:
    R20 = R5

LBB0_31:
    ...
    b  LBB0_34

#LBB0_33:                  # weird basic block?
#    R20 = R5

LBB0_34:
    ....
##################################################################

Resulting codes are correct. If I compile original subroutine with -O0,
result codes are also right.

I do not have any clue what happens when compiling with -O2.
Can someone make a suggestion?

-- 
杨勇勇 (Yang Yong-Yong)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130918/80fb3ac4/attachment.html>

Hi Yang,
>     bnz  R2, LBB0_34
>
> I do not have any clue what happens when compiling with -O2.
> Can someone make a suggestion?
Is the "bnz" instruction marked "isBarrier" in your TableGen
files? If
so, that would mean LLVM considers fallthrough impossible and decides
it can move LBB0_33 around at will. It's still very odd that it thinks
it can put it directly before LBB0_34 though.

It would be interesting to see the blocks before and after the "Basic
block placement" pass. Running llc with -print-after-all and/or -debug
might well shed some light on what's happening.

Other possible bugs are in implementations of AnalyzeBranch,
InsertBranch or RemoveBranch. They're target callbacks LLVM uses to do
its more invasive block movement.  The place to start debugging is
lib/CodeGen/MachineBlockPlacement.cpp. Something in there is probably
getting confused.

Cheers.

Tim.

Thank you very much, Tim.
I comment out "let isBarrier = 1" in the definition of the conditional
branch instruction and run again, it does work.

Best regards.


2013/9/18 Tim Northover <t.p.northover at gmail.com>
> Hi Yang,
>
> >     bnz  R2, LBB0_34
> >
> > I do not have any clue what happens when compiling with -O2.
> > Can someone make a suggestion?
>
> Is the "bnz" instruction marked "isBarrier" in your
TableGen files? If
> so, that would mean LLVM considers fallthrough impossible and decides
> it can move LBB0_33 around at will. It's still very odd that it thinks
> it can put it directly before LBB0_34 though.
>
> It would be interesting to see the blocks before and after the "Basic
> block placement" pass. Running llc with -print-after-all and/or -debug
> might well shed some light on what's happening.
>
> Other possible bugs are in implementations of AnalyzeBranch,
> InsertBranch or RemoveBranch. They're target callbacks LLVM uses to do
> its more invasive block movement.  The place to start debugging is
> lib/CodeGen/MachineBlockPlacement.cpp. Something in there is probably
> getting confused.
>
> Cheers.
>
> Tim.
>


-- 
杨勇勇 (Yang Yong-Yong)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130919/121b856c/attachment.html>