[llvm-bugs] [Bug 47603] New: [x86] Redundant XORs generated withwith BSR from "__builtin_clz".

[via llvm-bugs]

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

            Bug ID: 47603
           Summary: [x86] Redundant XORs generated withwith BSR from
                    "__builtin_clz".
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: ToHe_EMA at gmx.de
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Consider the following simple C function to be compiled with Clang:

char Func(unsigned DataOffset)
{
        return 31 ^ __builtin_clz(DataOffset);
}

Unfortunately it compiles to this assembly:

bsr     eax, edi
xor     eax, 31
xor     al, 31
ret

The relevant LLVM IR is as follows:

declare i32 @llvm.ctlz.i32(i32, i1 immarg) #1
define signext i8 @Func(i32 %0) {
  %2 = tail call i32 @llvm.ctlz.i32(i32 %0, i1 true)
  %3 = trunc i32 %2 to i8
  %4 = xor i8 %3, 31
  ret i8 %4
}

Obviously the two XORs should be entirely eliminated in the generated machine
code. This problem only occurs if the return type is a 8 bit integer (char).
For 16 bit, 32 bit and 64 bit integers the xors are elided correctly. Another
variant that leads to the same issue (without an 8 bit integer) is this:

extern char Lookup[32];
int LookupFunc(unsigned DataOffset)
{
        return Lookup[31 ^ __builtin_clz(DataOffset)];
}

With results in the following relevant LLVM IR code:

@Lookup = external dso_local local_unnamed_addr global [32 x i8], align 16
declare i32 @llvm.ctlz.i32(i32, i1 immarg) #1
define i32 @LookupFuncj(i32 %0) {
  %2 = tail call i32 @llvm.ctlz.i32(i32 %0, i1 true)
  %3 = xor i32 %2, 31
  %4 = zext i32 %3 to i64
  %5 = getelementptr inbounds [32 x i8], [32 x i8]* @Lookup, i64 0, i64 %4
  %6 = load i8, i8* %5, align 1
  %7 = sext i8 %6 to i32
  ret i32 %7
}

-- 
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/20200921/be1a6d1f/attachment-0001.html>