search for: isunordered

...gt; Ex: @llvm.memcpy_element_atomic — work was already started to introduce >> this one in D27133, but could be backed out and restarted. >> Intrinsic prototype: @llvm.memcpy_element_atomic.<overload desc>(<ty>* >> dest, <ty>* src, <ty> len, i32 align, i2 isunordered, i16 element_size) >> Semantics: >> * Will do a memcpy of len bytes from src to dest. >> * len must = k * lcm( #bytes in dest type, #bytes in src type), for >> some non-negative integer k [note: lcm = least-common multiple] >> * load/store size giv...

...ch of the memory intrinsics. Ex: @llvm.memcpy_element_atomic — work was already started to introduce this one in D27133, but could be backed out and restarted. Intrinsic prototype: @llvm.memcpy_element_atomic.<overload desc>(<ty>* dest, <ty>* src, <ty> len, i32 align, i2 isunordered, i16 element_size) Semantics: * Will do a memcpy of len bytes from src to dest. * len must = k * lcm( #bytes in dest type, #bytes in src type), for some non-negative integer k [note: lcm = least-common multiple] * load/store size given by the constant power-of-2 parameter “...

...D ******************** 207> Script: 207> -- 207> D:/src/llvm/build/vs2013/Debug/bin/clang.EXE -cc1 -internal-isystem D:\src\llvm\build\vs2013\Debug\bin\..\lib\clang\3.5.0\include -std=c99 D:\src\llvm\tools\clang\test\CodeGen\2004-06-17-UnorderedCompares.c -emit-llvm -o - | grep -v llvm.isunordered | D:/src/llvm/build/vs2013/Debug/bin\not.EXE grep call 207> -- 207> Exit Code: 127 207> 207> Command Output (stdout): 207> -- 207> Command 0: "grep" "-v" "llvm.isunordered" 207> Command 0 Result: 127 207> Command 0 Output: 207> 207>...

...:319:9: error: '::islessequal' has not been declared using ::islessequal; ^ llvm-3.8.0.src/projects/libcxx/include/cmath:320:9: error: '::islessgreater' has not been declared using ::islessgreater; ^ llvm-3.8.0.src/projects/libcxx/include/cmath:321:9: error: '::isunordered' has not been declared using ::isunordered; ^ llvm-3.8.0.src/projects/libcxx/include/cmath:322:9: error: '::isunordered' has not been declared using ::isunordered; ^ llvm-3.8.0.src/projects/libcxx/include/cmath:328:9: error: '::abs' has not been declared using...

...c (with certain flags): x.cbe.c:130: warning: comparing floating point with == or != is unsafe Now, C99 provides a macro for this kind of stuff, but unfortunately ANSI C doesn't have something like this (for unordered testing) AFAIK. *If* we would be using C99 the code could look like: return isunordered(X, Y); return !isunordered(X, Y); However the assembly code generated is much shorter if I am using the C99 macros, both on gcc and llvm-gcc. This raises 2 issues: * can llvm_fcmp_ord/uno be implemented in ANSI/ISO C differently, which doesn't generate a warning, *and* generates optimal code...

....bswap -> llvm.bswap.i16, llvm.bswap.i32, llvm.bswap.i64 llvm.ctpop -> llvm.ctpop.i8, llvm.ctpop.i16, llvm.ctpop.i32, llvm.ctpop.i64 llvm.ctlz -> llvm.ctlz.i8, llvm.ctlz.i16, llvm.ctlz.i32, llvm.ctlz.i64 llvm.cttz -> llvm.cttz.i8, llvm.cttz.i16, llvm.cttz.i32, llvm.cttz.i64 llvm.isunordered -> llvm.isunordered.f32, llvm.isunordered.f64 llvm.sqrt -> llvm.sqrt.f32, llvm.sqrt.f64 Thanks, Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message...

...e.c:130: warning: comparing floating point with == or != is unsafe > > Now, C99 provides a macro for this kind of stuff, but unfortunately > ANSI C doesn't have something like this (for unordered testing) AFAIK. > > *If* we would be using C99 the code could look like: > return isunordered(X, Y); > return !isunordered(X, Y); > > However the assembly code generated is much shorter if I am using the > C99 macros, both on gcc and llvm-gcc. > > This raises 2 issues: > * can llvm_fcmp_ord/uno be implemented in ANSI/ISO C differently, > which doesn't generate a...

Greetings! I have been building llvm-3.6.x, 3.7.1 and 3.7.2 with (glibc-2.12.1, binutils-2.24, gcc-4.9.2) almost same set if CMake flags. However while building LLVM-3.8.0 using same CMake flags I am observing projects/libcxx/include/cmath errors... ...'::signbit' has not been declared ...'::fpclassify' has not been declared ...'::isfinite' has not been declared ...

...e quiet (non > floating-point exception raising) > versions of the relational operators, and other comparison macros > that facilitate writing > efficient code that accounts for NaNs without suffering the > ‘‘invalid’’ floating-point exception. > */ > return isunordered(x, x); > } > > The comment text is from 7.12.14 of the C standard draft. I'm hoping to > avoid any scenario under which it is ok to raise an exception in that code > (eliminate any questions about the clang front-end behavior / FENV_ACCESS). isunordered (like isnan) is a diff...

...e > advice in the docs to consult the list before doing something rash. Always a good idea! :) Instead of adding an instruction, I'd suggest adding an intrinsic. You can mark intrinsics as not reading/writing to memory (see lib/Analysis/BasicAliasAnalysis.cpp for example, look for llvm.isunordered to see how it is handled). > What I want to do is provide a way to identify variable names and > source locations that doesn't affect the effectiveness of > optimizations. This is not the same problem as supporting debug info, > because I don't care about being able to look up...

I've been thinking of adding an instruction, and I'm following the advice in the docs to consult the list before doing something rash. What I want to do is provide a way to identify variable names and source locations that doesn't affect the effectiveness of optimizations. This is not the same problem as supporting debug info, because I don't care about being able to look up

...ocs to consult the list before doing something rash. > > Always a good idea! :) Instead of adding an instruction, I'd suggest > adding an intrinsic. You can mark intrinsics as not reading/writing to > memory (see lib/Analysis/BasicAliasAnalysis.cpp for example, look for > llvm.isunordered to see how it is handled). OK, I didn't know about that - thanks. > > What I want to do is provide a way to identify variable names and > > source locations that doesn't affect the effectiveness of > > optimizations. This is not the same problem as supporting debug info,...

...P>(Denominator)) + return false; + // The denominator is a zero constant - we can't speculate here. + if (m_AnyZero().match(Denominator)) + return false; + return true; + } case Instruction::Load: { const LoadInst *LI = cast<LoadInst>(Inst); if (!LI->isUnordered() || ``` I did my tests using a powerpc64le target, but I couldn't find any target specific login involved in this transform. In any case, I wanted to drop the questions: - is there any target that would benefit from speculative fp divisions? - is there any target for which fp division does no...

...r is a zero constant - we can't speculate here. >> + if (m_AnyZero().match(Denominator)) >> + return false; >> + return true; >> + } >> case Instruction::Load: { >> const LoadInst *LI = cast<LoadInst>(Inst); >> if (!LI->isUnordered() || >> ``` >> I did my tests using a powerpc64le target, but I couldn't find any >> target specific login involved in this transform. In any case, I >> wanted to drop the questions: >> >> - is there any target that would benefit from speculative fp divisio...

...instance, to track register spills >>> back to which variable spilled. >> >> I think the above will work for you, you can make it ignored or deal with >> it however you want using the intrinsic lowering code. Check out how >> other intrinsics are handled (e.g. llvm.isunordered, which is handled by >> the code generators and llvm.dbg.* which are not) for ideas. >> >>> What problems can you think of with that approach? Am I asking for >>> trouble with passes, or would a semantically meaningless 'marker' >>> instruction be OK?...

...er spills > >>> back to which variable spilled. > >> > >> I think the above will work for you, you can make it ignored or deal with > >> it however you want using the intrinsic lowering code. Check out how > >> other intrinsics are handled (e.g. llvm.isunordered, which is handled by > >> the code generators and llvm.dbg.* which are not) for ideas. > >> > >>> What problems can you think of with that approach? Am I asking for > >>> trouble with passes, or would a semantically meaningless 'marker' > >&gt...

Hi, I’ve been investigating https://bugs.llvm.org/show_bug.cgi?id=43374, which is about clang/llvm producing code that triggers a floating point exception when x is NaN, when targeting ARM, in the below code example. int bar(float x) { return x!=x ? 0 : 1; } The C99 standard states in section 7.12.14: """ The relational and equality operators support the usual mathematical

...P>(Denominator)) + return false; + // The denominator is a zero constant - we can't speculate here. + if (m_AnyZero().match(Denominator)) + return false; + return true; + } case Instruction::Load: { const LoadInst *LI = cast<LoadInst>(Inst); if (!LI->isUnordered() || ``` I did my tests using a powerpc64le target, but I couldn't find any target specific login involved in this transform. In any case, I wanted to drop the questions: - is there any target that would benefit from speculative fp divisions? - is there any target for which fp division does no...

...uired SDNodes ? > for example I am trying to do it in LowerBR_CC as shown below: > getFPCCtoMBCC(CC,TCC); > TargetCC = DAG.getConstant(TCC, dl, MVT::i8); > Flag = DAG.getNode(XXXISD::FCMP, dl, MVT::Glue, LHS, RHS, > TargetCC); > if (isUnordered) { > TCC = XXX::COND_UN; > TargetCC = DAG.getConstant(TCC, dl, MVT::i8); > SDValue UnComp = DAG.getNode(XXX::FCMP, dl, MVT::Glue, LHS, RHS, > TargetCC); > Flag = DAG.getNode(ISD::OR, dl, MVT::Glue, Flag, UnComp); > }...

...c.edu/docs/AliasAnalysis.html#globalsmodref LLVM Core Additions: 11. The BinaryOperator class now has a BinaryOperator::createAdd(...) method as a shortcut for BinaryOperator::create(Instruction::Add, ...). It also has methods for all of the other opcodes too :) 12. LLVM now has an llvm.isunordered intrinsic for unordered floating point comparison support. Code Generator Changes: 13. Vladimir Prus contributed a nice ConstantExpr lowering pass that makes it substantially easier to write instruction selectors for LLVM. 14. The target-independent live-variable analysis is quicker and...