[LLVMbugs] [Bug 21205] New: [Reassociation w/fast-math] Assert when calling getNeg() on undef of type float

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Oct 8 05:46:08 PDT 2014


http://llvm.org/bugs/show_bug.cgi?id=21205

            Bug ID: 21205
           Summary: [Reassociation w/fast-math] Assert  when calling
                    getNeg() on undef of type float
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: ASSIGNED
          Severity: normal
          Priority: P
         Component: Transformation Utilities
          Assignee: mcrosier at codeaurora.org
          Reporter: mcrosier at codeaurora.org
                CC: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu,
                    resistor at mac.com
    Classification: Unclassified

An assertion is hit in the Reassociation pass on x86 at -O2 -ffast-math with
the following code:

a, b;
fn1() {
  switch (0)
  case 0: {
    float c;
    b = a - c - 1;
  }
}


The SROA introduces the following instruction:
  %sub = fsub fast float %conv, undef

Complete function:
define i32 @fn1() {
entry:
  %0 = load i32* @a, align 4, !tbaa !1
  %conv = sitofp i32 %0 to float
  %sub = fsub fast float %conv, undef
  %sub1 = fsub fast float %sub, 1.000000e+00
  %conv2 = fptosi float %sub1 to i32
  store i32 %conv2, i32* @b, align 4, !tbaa !1
  ret i32 undef
}

The reassociation pass is trying to canonicalize X-Y into X+(0-Y) to expose
more opportunities for reassociation.  In this case, Y is undef with type
float, but getNeg() is being called, as opposed to getFNeg().

The logic in the pass looks like this:

static Value *NegateValue(Value *V, Instruction *BI) {
  if (ConstantFP *C = dyn_cast<ConstantFP>(V))
    return ConstantExpr::getFNeg(C);
  if (Constant *C = dyn_cast<Constant>(V))
    return ConstantExpr::getNeg(C);
...

I guess an undef of type float isn't a ConstantFP...  ..continuing to
investigate a solution.

-- 
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/20141008/185b502d/attachment.html>


More information about the llvm-bugs mailing list