[llvm-bugs] [Bug 24886] New: what is the canonical IR for a fabs operation?

[via llvm-bugs]

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

            Bug ID: 24886
           Summary: what is the canonical IR for a fabs operation?
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: spatel+llvm at rotateright.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Another round of "What is canonical IR?" is raised by the test in bug 22428:

#include <math.h>
#include <string.h>

double fand1(double x) {
  unsigned long ix;
  memcpy(&ix, &x, 8);
  ix &= 0x7fffffffffffffffUL;
  memcpy(&x, &ix, 8);
  return x;
}

double fand2(double x) {
  return fabs(x);
}

$ ./clang -O2 22428.c -S -o - -emit-llvm
...
define double @fand1(double %x) #0 {
entry:
  %0 = bitcast double %x to i64
  %and = and i64 %0, 9223372036854775807
  %1 = bitcast i64 %and to double
  ret double %1
}

define double @fand2(double %x) #0 {
entry:
  %call = tail call double @fabs(double %x) #2
  ret double %call
}

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

My guess is that neither of these is canonical. We should be transforming both
of these into the LLVM intrinsic, so we have something the backend knows how to
optimize and so we don't have a dependency on an external math lib.

Note: I'm assuming that the format of an LLVM 'double' matches the normal
(IEEE-specified?) format, so the sign bit is the high bit. This isn't actually
specified in the LangRef though:
http://llvm.org/docs/LangRef.html#floating-point-types

If that assumption isn't valid, we're in more trouble than I thought. :)

-- 
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/20150920/c881838e/attachment.html>