[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