[LLVMdev] Why can't comparisons with negative zero be simplified? (original) (raw)

Sean Silva chisophugis at gmail.com
Mon Jul 6 15:06:34 PDT 2015

+Matt who is the one that originally committed this (r225265).

-- Sean Silva

On Mon, Jul 6, 2015 at 2:13 PM, Robison, Arch <arch.robison at intel.com> wrote:

In InstCombineCompares.cpp, routine InstCombiner::FoldFCmpIntToFPCst, there are these lines:

// Comparisons with zero are a special case where we know we won't lose // information. bool IsCmpZero = RHS.isPosZero(); // If the conversion would lose info, don't hack on this. if ((int)InputSize > MantissaWidth && !IsCmpZero) return nullptr; Why check for positive zero instead of checking for any kind of zero? My reading of IEEE 754-2008 is that floating-point comparison operations cannot distinguish a negative zero from a positive zero. Further supporting this is that fact that http://llvm.org/docs/LangRef.html <https://urldefense.proofpoint.com/v2/url?u=http-3A_llvm.orgdocsLangRef.html&d=AwMFAg&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4bhmuhMHA&m=ZaWNNVonUS-YjLoXztqD5ve4xvIIhIXYdnk3Xqwz8w&s=xonYObEo1TXUyjK3RYC4Pg3kAaSvaYyLnvaiq5G1N0&e=> describes the difference between “ordered” and “unordered” as pertaining to QNAN operands, with no mention of negative zero. I tried fixing the issue, but then the following test in cast-int-fcmp-eq-0.ll fails: ; CHECK-LABEL: @i32castcmpoeqintn0uitofp( ; CHECK: uitofp ; CHECK: fcmp oeq define i1 @i32castcmpoeqintn0uitofp(i32 %i) { %f = uitofp i32 %i to float %cmp = fcmp oeq float %f, -0.0 ret i1 %cmp } Is this test really justified, or is it just reinforcing an oversight? - Arch D. Robison

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150706/9b0c6074/attachment.html>

More information about the llvm-dev mailing list