[llvm-bugs] [Bug 28852] New: Machine code sinking is blocked when SUBREG_TO_REG is seen

[via llvm-bugs]

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

            Bug ID: 28852
           Summary: Machine code sinking is blocked when SUBREG_TO_REG is
                    seen
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: wmi at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

For the testcase 1.c below:
-------------------------------------
unsigned x;

void foo(unsigned long value, unsigned kLengthBits, unsigned* bits, unsigned
long *bit_buffer_64) {
  long tmp = kLengthBits * x + 3;
  long length = tmp * 5;
  int v = 64 - value;
  if (__builtin_expect(*bits < (unsigned)(v), 0)) {
    *bit_buffer_64 += (value + length);
    *bits = length;
  }
}
-------------------------------------

length is only used in a cold branch, so it is beneficial to sink the
computation chain targeted to length to the cold branch. 

llvm moves "tmp * 5" to the cold branch, but doesn't move "kLengthBits * x +
3".
~/workarea/llvm-r277486/dbuild/bin/clang -O2 -S 1.c
foo:                                    # @foo
        .cfi_startproc
# BB#0:                                 # %entry
                                        # kill: %ESI<def> %ESI<kill> %RSI<def>
        imull   x(%rip), %esi
        addl    $3, %esi
        movl    $64, %eax
        subl    %edi, %eax
        cmpl    %eax, (%rdx)
        jb      .LBB0_1
.LBB0_2:                                # %if.end
        retq
.LBB0_1:                                # %if.then
        leaq    (%rsi,%rsi,4), %rax
        addq    %rax, %rdi
        addq    %rdi, (%rcx)
        movl    %eax, (%rdx)
        jmp     .LBB0_2
.Lfunc_end0:
        .size   foo, .Lfunc_end0-foo
        .cfi_endproc

gcc moves all the computations related with length to the cold branch.
~/workarea/gcc-r233722/build/install/bin/gcc -O2 -S 1.c
foo:
.LFB0:
        .cfi_startproc
        movl    $64, %eax
        subl    %edi, %eax
        cmpl    (%rdx), %eax
        ja      .L4
        rep ret
        .p2align 4,,10
        .p2align 3
.L4:
        imull   x(%rip), %esi
        leal    3(%rsi), %eax
        leaq    (%rax,%rax,4), %rax
        leaq    (%rdi,%rax), %rsi
        addq    %rsi, (%rcx)
        movl    %eax, (%rdx)
        ret
        .cfi_endproc

llvm doesn't move "kLengthBits * x + 3" because it see a SUBREG_TO_REG which is
generated by a zext for "kLengthBits * x + 3" from i32 to i64.

MachineSinking pass will stop sink instructions once SUBREG_TO_REG is seen.

  /// Return true if the instruction should be sunk by MachineSink.
  ///
  /// MachineSink determines on its own whether the instruction is safe to
sink;
  /// this gives the target a hook to override the default behavior with
regards
  /// to which instructions should be sunk.
  /// The default behavior is to not sink insert_subreg, subreg_to_reg, and
  /// reg_sequence. These are meant to be close to the source to make it easier
  /// to coalesce.
  virtual bool shouldSink(const MachineInstr &MI) const {
    return !MI.isInsertSubreg() && !MI.isSubregToReg() && !MI.isRegSequence();
  }

The check above was added at r114631.
------------------------------------------------------------------------
r114631 | evancheng | 2010-09-22 23:53:00 -0700 (Wed, 22 Sep 2010) | 3 lines

Don't sink insert_subreg, subreg_to_reg, reg_sequence. They are meant to be
close to their sources to facilitate coalescing.

------------------------------------------------------------------------

Considering the check was added before greedy register allocation was
introduced, is it still necessary for coalescing today?

-- 
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/20160804/de802208/attachment.html>