[llvm-bugs] [Bug 34641] New: x86: shld peephole missed with masked shift-counts

[via llvm-bugs]

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

            Bug ID: 34641
           Summary: x86: shld peephole missed with masked shift-counts
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: peter at cordes.ca
                CC: llvm-bugs at lists.llvm.org

unsigned shld_safe(unsigned a, unsigned b, unsigned n){
        //n=13;
        a <<= n&31;
        b >>= (32-n)&31; // (32-n)&31
        return a|b;
}
https://godbolt.org/g/MxuAht


clang 6.0.0 (trunk 313348) -march=skylake -O3

        shlx    ecx, edi, edx
        neg     edx              # at least 32&31 optimized to 0
        shrx    eax, esi, edx
        or      eax, ecx
        ret

It takes even more instructions without BMI2, of course.

Without the `&31`, this optimizes to SHLD, so the peephole needs to learn that
SHLD masks the shift-count with &31 for 32-bit or smaller operand-size.  (Or
with &63 for 64-bit operand-size).  http://felixcloutier.com/x86/SHLD.html.

        mov     ecx, edx
        shld    edi, esi, cl
        mov     eax, edi
        ret

I didn't test with SHRD, but I assume it's the same.


BTW, this peephole activates even with `-march=znver1` or other AMD
architectures, where shld r,r,cl is 7 uops...  SHLD may still be worth it
without BMI2 for the variable-count case, but probably not when BMI2 is
available and tuning for AMD.

SHLD is probably still a good idea for tune=generic, especially with
variable-count; it's great on Intel, and only slightly worse than the amount of
instructions it takes to work around it on AMD, unless VectorPath instructions
are really bad in the front-end.)

-- 
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/20170916/3fcbf5d0/attachment-0001.html>