search for: huge_valf

all, this is all probably very old news and probably fixed in a later OSX, but..... on my 10.4.11 machine, math.h has (IMHO this bug) #define HUGE_VALF 1e50f this compiles when I build LLVM using "configure", but not with "cmake", probably to do with different C-standard-ness and pedantic-ness switches.... I would recommend LLVM Support not import the HUGE_VAL, HUGE_VALF feature, and instead use its own definition, I r...

...: error: floating constant exceeds range of 'double' LiveIntervalAnalysis.cpp:328: error: floating constant exceeds range of 'double' LiveIntervalAnalysis.cpp:1350: error: floating constant exceeds range of 'double' If I disable -pedantic the build succeeds. NOTE: HUGE_VALF should be used instead of (float)HUGE_VAL. Proposed patch enclosed. -------------- next part -------------- A non-text attachment was scrubbed... Name: HUGE_VAL.patch Type: application/octet-stream Size: 5451 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachment...

...le' > LiveIntervalAnalysis.cpp:328: error: floating constant exceeds range > of 'double' > LiveIntervalAnalysis.cpp:1350: error: floating constant exceeds range > of 'double' > > If I disable -pedantic the build succeeds. > > > > > NOTE: HUGE_VALF should be used instead of (float)HUGE_VAL. Proposed > patch enclosed. > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo...

..., should the condition be: if (ImpUse && MI != ReMatDefMI && MI != ReMatOrigDefMI) instead of: if (ImpUse && MI != ReMatDefMI) ? After all, ReMatDefMI is a clone of the original def instruction (ReMatOrigDefMI). I'm seeing bad things happen, with intervals getting HUGE_VALF set as their weight because they happen to be used in RegMatOrigDefMI and MI doesn't match ReMatDefMI (because it's a clone and not really in the IR at all!). -Dave

Thanks for the updates! Minor comments: + if (!Accuracy) + // If it's not a floating point number then it must be 'fast'. + return HUGE_VALF; Can we add an assert instead of a comment? It's just as documenting and will catch any goofs. + // If it's not a floating point number then it must be 'fast'. + return !isa<ConstantFP>(MD->getOperand(0)); Here as well. + if (ConstantFP *CFP0 = dyn_cast_or_null<...

Hi, Any ideas why HUGE_VALF is not accepted as a float constant on Mac OS X 10.4.11 (Intel)? ./llvm/include/llvm/CodeGen/LiveInterval.h:569: error: floating constant exceeds range of 'float' ./llvm/include/llvm/CodeGen/LiveInterval.h:574: error: floating constant exceeds range of 'float' llvm/lib/CodeGen/Calc...

Hi Chandler, > Minor comments: > + if (!Accuracy) > + // If it's not a floating point number then it must be 'fast'. > + return HUGE_VALF; > > Can we add an assert instead of a comment? It's just as documenting and will > catch any goofs. Done. > > + // If it's not a floating point number then it must be 'fast'. > + return !isa<ConstantFP>(MD->getOperand(0)); > > Here as well. >...

Here's a revised patch, plus patches showing how fpmath metadata could be turned on in clang and dragonegg (it seemed safest for the moment to condition on -ffast-math rather than on one of the flags implied by -ffast-math). Major changes: - The FPMathOperator class can no longer be used to change math settings, only to read them. Currently it can be queried for accuracy info. I split the

...eated for one of the spill intervals of %reg1235. It is marked as rematerializable with defining instruction: %reg1235<def> = FsMOVLPDrm %reg1097, 1, %reg1364, 8, Mem:LD(8,8) [tmp17641765 + 0] Note that this is the same instruction as above. %reg1097 is marked unspillable (weight set to HUGE_VALF). %reg1461 gets assigned XMM15 by the register allocator. Later on %reg1364 is spilled and assigned a stack slot. When rewriting instructions after regalloc, we come across this instruction: %XMM3<def> = MOVSDrr %reg1461, %R12<imp-use> %reg1461 was marked as rematerializable (from...

The attached patch is a first attempt at representing "-ffast-math" at the IR level, in fact on individual floating point instructions (fadd, fsub etc). It is done using metadata. We already have a "fpmath" metadata type which can be used to signal that reduced precision is OK for a floating point operation, eg %z = fmul float %x, %y, !fpmath !0 ... !0 = metadata