[llvm-bugs] [Bug 38541] New: Function has 8 identical return blocks

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=38541

            Bug ID: 38541
           Summary: Function has 8 identical return blocks
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: paulsson at linux.vnet.ibm.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 20687
  --> https://bugs.llvm.org/attachment.cgi?id=20687&action=edit
clang test case

For some reason, the attached function (unreduced from SPEC), ends up with 8
identical return blocks: 

.LBB0_29:
        mvi     160(%r2), 1
        lgfr    %r2, %r0
        lmg     %r6, %r15, 48(%r15)
        br      %r14
.LBB0_30:
        mvi     160(%r2), 1
        lgfr    %r2, %r0
        lmg     %r6, %r15, 48(%r15)
        br      %r14
...

This function was unrolled 8 times at the source level by the programmer.

Each MVI (Move Immediate) have identical register and immediate operands, but
the memory operands refer to different Values.

The SystemZ implementation of areMemAccessesTriviallyDisjoint() would not
return true in this case, as it only looks at the memory operands currently.
But implementing this does not seem to help or even get called with the MVIs in
this case. I suppose the CFG optimizer is already checking for identical
operands...

I am not sure how important this is, but unless I am missing something it seems
like an obvious case of improvement since one such return block should be
enough.

The Control Flow optimizer sees 8 identical blocks with just MVI + J:

     MVI killed renamable $r2d, 160, 1
     J %bb.36

These are conditionally jumped over blocks, each preceded with a BRC to the
block immediately after it. So it seems that CFGOpt thinks it's a good idea to
conditionally jump past them, instead of conditionally jumping to one such
block  (this is in itself a bit confusing to me, since I thought that generally
NT branches are preferred).

Only after Branch Probability Basic Block Placement have %bb.36 been inlined
into each such block, giving the blocks per above. I'm a bit confused since
judging from the name BB Placement shouldn't alter anything, or is some other
pass running also here?

Curious to hear what anybody has to say about this, and if there is anything in
the SystemZ backend that could be improved to help cases like this?

clang -cc1 -triple s390x-ibm-linux -S -target-cpu z13 -O3 -o out.s -x ir
./tc_8retblocks.bc

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180813/85cabbe6/attachment.html>