[llvm-bugs] [Bug 49403] New: branches containing only llvm.assume are not fully eliminated

[via llvm-bugs]

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

            Bug ID: 49403
           Summary: branches containing only llvm.assume are not fully
                    eliminated
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: jannh at google.com
          Reporter: jannh at google.com
                CC: llvm-bugs at lists.llvm.org

[patch in progress]

When a branch contains only a call to `llvm.assume`, the generated machine code
still contains the condition of that branch, even though the branch itself and
its body are gone.

The issue seems to be that the call to `llvm.assume` is only removed very late,
in the "CodeGen Prepare (codegenprepare)" pass; the resulting empty branch
survives the move into MIR and only disappears in the MIR pass "Control Flow
Optimizer (branch-folder)".

Reproducer:

```
define dso_local void @a(i64 %addr, i64 %addr2) {
entry:
  %cmp = icmp ne i64 %addr, %addr2
  %cmp1 = icmp eq i64 %addr, 0
  br i1 %cmp1, label %do_assume, label %after_assume

do_assume:
  tail call void @llvm.assume(i1 %cmp)
  br label %after_assume

after_assume:
  br i1 %cmp, label %end, label %call_b

call_b:
  tail call void @b(i64 %addr)
  br label %end

end:
  ret void
}
declare void @llvm.assume(i1 noundef)
declare void @b(i64)
```

Resulting X86 assembly:

```
# %bb.0:                                # %entry
        testq   %rdi, %rdi
        cmpq    %rsi, %rdi
        je      .LBB0_2
# %bb.1:                                # %end
        retq
.LBB0_2:                                # %call_b
        jmp     b at PLT                           # TAILCALL
```

If you remove the call to @llvm.assume from the testcase, the entire branch
including its condition disappears in the codegenprepare pass.

So the issue is probably that after CodeGenPrepare::optimizeCallInst() may have
killed the call instruction, we don't try to eliminate the block with
CodeGenPrepare::eliminateMostlyEmptyBlocks()? And this is the case because
CodeGenPrepare::runOnFunction() first calls eliminateMostlyEmptyBlocks(), then
runs the loop that calls optimizeBlock().

I'll try to send a patch for this in a bit.

-- 
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/20210303/cdac3077/attachment.html>