[llvm-bugs] [Bug 43481] New: [MIPS] Missing ANDI optimization

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Sep 27 08:27:54 PDT 2019


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

            Bug ID: 43481
           Summary: [MIPS] Missing ANDI optimization
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: MIPS
          Assignee: unassignedbugs at nondot.org
          Reporter: arichardson.kde at gmail.com
                CC: llvm-bugs at lists.llvm.org

We noticed that clang generates unnecessary SLL instructions in one of our
benchmark hot paths (and apparently GCC does not): https://godbolt.org/z/xKcCqT


Consider
```
#include <stdint.h>

uint64_t foo(uint64_t a)
{
    uint64_t b = a / 16;
    uint64_t c = b & 0x7UL;
    return ((uint64_t)1UL << c);
}
```

At present, the MIPS backend produces:
```
foo(unsigned long):                                # @foo(unsigned long)
        sll     $1, $4, 0
        srl     $1, $1, 4
        andi    $1, $1, 7
        daddiu  $2, $zero, 1
        jr      $ra
        dsllv   $2, $2, $1
```

The `sll` is introduced because the `srl` requires that its input be zero
extended (which, well, seems silly, but so it goes).  In any case, because
`andi` has a 16-bit immediate, some arithmetic and lookahead could find that
`0x7 << 4` fits and so make this be

```
        andi    $1, $4, 0x70
        srl     $1, $1, 4
        daddiu  $2, $zero, 1
        jr      $ra
        dsllv   $2, $2, $1
```

Alternatively, whatever's concluding that it can use 32-bit values internally
could stop doing that and this could instead just be

```
        dsrl    $1, $4, 4
        andi    $1, $1, 7
        daddiu  $2, $zero, 1
        jr      $ra
        dsllv   $2, $2, $1
```

This problem was found by Nathaniel Wesley Filardo and reported as
https://github.com/CTSRD-CHERI/llvm-project/issues/343

-- 
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/20190927/ba6be177/attachment.html>


More information about the llvm-bugs mailing list