[llvm-bugs] [Bug 50982] New: Constant bit manipulations are not always propagated resulting in missed optimizations

[via llvm-bugs]

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

            Bug ID: 50982
           Summary: Constant bit manipulations are not always propagated
                    resulting in missed optimizations
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: vgatherps at gmail.com
                CC: llvm-bugs at lists.llvm.org

It looks like the propagation of information from bit manipulations by
constants isn't properly propagated. Specifically, this appears to happen as a
consequence of optimizing/merging branches

Compiling the code


void a();
void b();
void c();


// This function cannot recognize that reaching the call to a()
// implies the call to c()
void test_intermediate_condition(int mask) {
    if (mask & 0b1) {
        a();
        mask |= 0b100;
    }
    if (mask & 0b10) {
        b();
    }
    if (mask & 0b100) {
        c();
    }
}

// This function recognizes that reaching the call to a()
// implies the call to c()
void test_no_intermediate_condition(int mask) {
    if (mask & 0b1) {
        a();
        mask |= 0b100;
    }
    b();
    if (mask & 0b100) {
        c();
    }
}

Results in the following code generated:
-----------------------------------
test_intermediate_change(int):          # @test_intermediate_change(int)
        pushq   %rbx
        movl    %edi, %ebx
        testb   $1, %bl
        jne     .LBB0_1
        testb   $2, %bl
        jne     .LBB0_3
.LBB0_4:
        testb   $4, %bl
        jne     .LBB0_6  # When this is reached from (LBB0_1),
                         # The tested bit is already set 
.LBB0_5:
        popq    %rbx
        retq
.LBB0_1:
        callq   a()
        orl     $4, %ebx
        testb   $2, %bl
        je      .LBB0_4 # This could jump to LBB0_6
                        # since LBB0_4 just checks the bit we set in
                        # ebx
.LBB0_3:
        callq   b()
        testb   $4, %bl
        je      .LBB0_5
.LBB0_6:
        popq    %rbx
        jmp     c()                           # TAILCALL

-----------

test_no_intermediate_change(int):       # @test_no_intermediate_change(int)
        pushq   %rbx
        movl    %edi, %ebx
        testb   $1, %bl
        jne     .LBB1_1
        callq   b()
        testb   $4, %bl
        jne     .LBB1_2
        popq    %rbx
        retq
.LBB1_1:
        callq   a()
        callq   b()
.LBB1_2:
        popq    %rbx
        jmp     c()                           # TAILCALL
-----------------

As noted in the generated assembly, the first function is not able to propagate
0b100 being set after the call to a() to the check of bit 0b100 in the call to
c().

The optimization is performed when an irrelevant check against the mask is
removed from the function, so llvm can certainly perform the optimization.

For what it's worth, I was able to produce code like:

or $4, %ebx
testq $4, %ebx
jne .....

in real life code, but was not able to massage something like this out of a
reduced example

-- 
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/20210705/4c6da659/attachment.html>