search for: isfporfpvector

...ported some code to > LLVM 2.7, and not in the release notes (I had sent a private email > some time ago) : > > --- ReleaseNotes.html.old 2010-04-22 09:43:42.000000000 +0200 > +++ ReleaseNotes.html 2010-04-22 10:27:22.000000000 +0200 > @@ -862,6 +862,18 @@ > <tt>isFPOrFPVector</tt> and <tt>isFPOrFPVector</tt> methods have been renamed > <tt>isIntegerTy</tt>, <tt>isIntOrIntVectorTy</tt>, <tt>isFloatingPointTy</tt>, > <tt>isFPOrFPVectorTy</tt> and <tt>isFPOrFPVectorTy</tt> respectively.&lt...

...I changes, some that hit me when I ported some code to LLVM 2.7, and not in the release notes (I had sent a private email some time ago) : --- ReleaseNotes.html.old 2010-04-22 09:43:42.000000000 +0200 +++ ReleaseNotes.html 2010-04-22 10:27:22.000000000 +0200 @@ -862,6 +862,18 @@ <tt>isFPOrFPVector</tt> and <tt>isFPOrFPVector</tt> methods have been renamed <tt>isIntegerTy</tt>, <tt>isIntOrIntVectorTy</tt>, <tt>isFloatingPointTy</tt>, <tt>isFPOrFPVectorTy</tt> and <tt>isFPOrFPVectorTy</tt> respectively.</li>...

Ok, the LLVM 2.7 release notes are in near final shape. Please take a look and suggest improvements (or, better yet, just commit improvements if you have commit access): http://llvm.org/docs/ReleaseNotes.html Things still needed are marked with FIXMEs. These include: 1. Clang needs a blurb describing what's new in 2.7. Have the clang folks been doing anything for the last 6 months? 2. I

...ions that would be interesting for the type checker to verify: (* Easy; is encoded in the C++ type system. *) isa<Constant>(x) && isa<Constant>(y) (* Harder; assertions in C++. *) x->getType() == y->getType() x->getType()->isIntOrIntVector() || x->getType()->isFPOrFPVector() I was very impressed that Bryan made build_call statically type check! Still, there are also some problems that I don't think are tractable. Consider param 1 f. Even if the type checker knows the type of f via something like `Function of ('a v -> 'b v -> 'c v) v, I don...

...n*)in ccHkdHVT.o "llvm::BinaryOperator::Create(llvm::Instruction::BinaryOps, llvm::Value*, llvm::Value*, llvm::Twine const&, llvm::Instruction*)", referenced from: BinaryExprAST::Codegen() in ccHkdHVT.o BinaryExprAST::Codegen() in ccHkdHVT.o "llvm::Type::isFPOrFPVector() const", referenced from: BinaryExprAST::Codegen() in ccHkdHVT.o "llvm::Value::setName(llvm::Twine const&)", referenced from: BinaryExprAST::Codegen() in ccHkdHVT.o BinaryExprAST::Codegen() in ccHkdHVT.o CallExprAST::Codegen() in ccH...

I was talking to Gordon on #llvm earlier, and he challenged me with coming up with a way to improve the ocaml binding's type safety. We can't go letting haskell beat us now, can we? I think I got an easy solution with phantom types. For those who don't know what the problem is, the ocaml bindings share one type between whole class branches (like values). This means we need to downcast

...m::BinaryOperator::Create(llvm::Instruction::BinaryOps, > llvm::Value*, llvm::Value*, llvm::Twine const&, llvm::Instruction*)", > referenced from: > BinaryExprAST::Codegen() in ccHkdHVT.o > BinaryExprAST::Codegen() in ccHkdHVT.o > "llvm::Type::isFPOrFPVector() const", referenced from: > BinaryExprAST::Codegen() in ccHkdHVT.o > "llvm::Value::setName(llvm::Twine const&)", referenced from: > BinaryExprAST::Codegen() in ccHkdHVT.o > BinaryExprAST::Codegen() in ccHkdHVT.o > Call...