[LLVMbugs] [Bug 21637] New: [AArch64] A57LoadBalancing rewrites registers and introduces miscompile

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Nov 21 13:48:15 PST 2014


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

            Bug ID: 21637
           Summary: [AArch64] A57LoadBalancing rewrites registers and
                    introduces miscompile
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: ASSIGNED
          Severity: normal
          Priority: P
         Component: Backend: AArch64
          Assignee: james.molloy at arm.com
          Reporter: mcrosier at codeaurora.org
                CC: apazos at codeaurora.org, llvmbugs at cs.uiuc.edu,
                    t.p.northover at gmail.com, zhaoshiz at codeaurora.org
    Classification: Unclassified

Unfortunately, I can't reproduce this on top of trunk, but I'll describe the
issue as best I can.

I have some IR that look like the following:

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

  %call8.i = tail call double @floor(double %div7.i)
  %mul9.i = fmul double %call8.i, 6.000000e+00
  %sub10.i = fsub double %div3.i, %mul9.i

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

Lowering of the floor instruction results in two instructions being emitted:

1.) FRINTMSr to compute the floor value and
2.) FRINTXDr to check for an exception if the result was rounded (base on Tim's
comments on IRC)

See AArch64ISelDAGToDAG::SelectLIMB() for the implementation details.

Also from AArch64InstrInfo.td:

// FRINTX is inserted to set the flags as required by FENV_ACCESS ON behavior
// in the C spec. Setting hasSideEffects ensures it is not DCE'd.
// <rdar://problem/13715968>
// TODO: We should really model the FPSR flags correctly. This is really ugly.
let hasSideEffects = 1 in {
defm FRINTX : SingleOperandFPData<0b1110, "frintx", frint>;
}

The FRINTXDr instruction defines a D register, but it has not use and is marked
dead.

    %D0<def,dead> = FRINTXDr %D28<kill>;

Thus, the RegisterScavenger is free to scavenge this register.

----

Coming into the LoadBalancing pass we have MachineInstrs like the below.
The A57LoadBalancing pass then rewrites D11 to D0 introducing the correctness
issue:

    %D11<def> = FMULDrr %D30<kill>, %D26<kill>;
    %D5<def> = FSUBDrr %D10<kill>, %D31<kill>;
    %D0<def,dead> = FRINTXDr %D28<kill>;
    %D6<def> = FSUBDrr %D14<kill>, %D11<kill>;

becomes:

    %D0<def> = FMULDrr %D30<kill>, %D26<kill>;
    %D5<def> = FSUBDrr %D10<kill>, %D31<kill>;
    %D0<def,dead> = FRINTXDr %D28<kill>;
    %D6<def> = FSUBDrr %D14<kill>, %D0<kill>;

FSUBDrr is now using the incorrect value from the FRINTXDr instruction.

Tim suggest the pass is not correctly checking liveness, which seems
reasonable, but I'm not familiar with the pass.

-- 
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/20141121/c7eaa62b/attachment.html>


More information about the llvm-bugs mailing list