similar to: [LLVMdev] Changes between 2.6 and 2.7: SSA Verifier and visitFreeInst

Jianzhou Zhao wrote: > Hi llvm, > > 1) The lib/VMCore/Verifier.cpp in 2.7 implements Verifier::VerifyType, > which is empty in 2.6. I noticed that it does not check all types, > for example, UnionTyID, OpaqueTyID, LabelTyID, MetadataTyID > and etc are ignored in the 'default' branch. Does it mean we dont > need to check them? We do need to check union. I'll add

On Mar 6, 2010, at 9:13 AM, Jianzhou Zhao wrote: > Hi llvm, > > 1) The lib/VMCore/Verifier.cpp in 2.7 implements Verifier::VerifyType, > which is empty in 2.6. I noticed that it does not check all types, > for example, UnionTyID, OpaqueTyID, LabelTyID, MetadataTyID > and etc are ignored in the 'default' branch. Does it mean we dont > need to check them? They are

On Sat, Mar 6, 2010 at 2:35 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Jianzhou Zhao wrote: >> >> Hi llvm, >> >> 1) The lib/VMCore/Verifier.cpp in 2.7 implements Verifier::VerifyType, >> which is empty in 2.6. I noticed that it does not check all types, >> for example, UnionTyID, OpaqueTyID, LabelTyID, MetadataTyID >> and etc are ignored in

On Sat, Mar 6, 2010 at 2:14 PM, Chris Lattner <clattner at apple.com> wrote: > > On Mar 6, 2010, at 9:13 AM, Jianzhou Zhao wrote: > >> Hi llvm, >> >> 1) The lib/VMCore/Verifier.cpp in 2.7 implements Verifier::VerifyType, >> which is empty in 2.6. I noticed that it does not check all types, >> for example, UnionTyID, OpaqueTyID, LabelTyID, MetadataTyID

Hi LLVM, In lib/VMCare/Verifier.cpp::visitInstruction, we have such code 1287 // Check that the return value of the instruction is either void or a legal 1288 // value type. 1289 Assert1(I.getType() == Type::getVoidTy(I.getContext()) || 1290 I.getType()->isFirstClassType() 1291 || ((isa<CallInst>(I) || isa<InvokeInst>(I)) 1292 &&

On Jan 16, 2010, at 11:15 AM, Talin wrote: > OK here's the patch for real this time :) > > On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test > "union.ll" does not work, so you probably don't want to check this > in as is. However, I'd be interested in any

This patch adds a UnionType to DerivedTypes.h. It also adds code to the bitcode reader / writer and the assembly parser for the new type, as well as a tiny .ll test file in test/Assembler. It does not contain any code related to code generation or type layout - I wanted to see if this much was acceptable before I proceeded any further. Unlike my previous patch, in which the Union type was

OK here's a new version of the patch - and the unions.ll test actually passes :) On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 16, 2010, at 11:15 AM, Talin wrote: > > OK here's the patch for real this time :) >> >> On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: >> Here's a work

On Jan 6, 2010, at 12:45 PM, Talin wrote: > This patch adds a UnionType to DerivedTypes.h. Cool. When proposing an IR extension, it is usually best to start with a LangRef.html patch so that we can discuss the semantics of the extension. Please do write this before you get much farther. I assume that you want unions usable in the same situations as a struct. However, how do "constant

I've made all the suggested changes - however, I'm having a bit of problem running the tests. I started "make check" and several hours later it had only made it through about 1/3 of the tests. I'm not sure what the deal is. On Mon, Jan 18, 2010 at 1:40 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 16, 2010, at 11:15 AM, Talin wrote: > > OK

OK here's the patch for real this time :) On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test "union.ll" > does not work, so you probably don't want to check this in as is. However, > I'd be interested in any feedback you're willing to give. > > -- > -- Talin

Here's a work in progress of the union patch. Note that the test "union.ll" does not work, so you probably don't want to check this in as is. However, I'd be interested in any feedback you're willing to give. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, The checking about that if this is a terminator that it is at the end of the block has been applied twice (bellow). One is at Verifier::visitInstruction, and the other is at Verifier::visitTerminatorInst. Since visitInstruction is called when visiting each instruction, the checking at visitTerminatorInst seems redundant to me. Did I miss any case? void Verifier::visitInstruction(Instruction

I too have stumbled over this. Wouldn't it be a good idea to add a check for this to the function verifier pass? Hans Anton Korobeynikov wrote: > Hello > >> I naively though it would pick up the call convention from the declaration >> as there was no error like we have when the wrong number of parameters is >> used. > This is not an error, you're just

Hi, Does LLVM have passes that do translations between GCC RTL and LLVM SSA, RTL -> SSA and SSA -> RTL? Thanks. -- Jianzhou

On Jun 22, 2010, at 10:29 AM, Jianzhou Zhao wrote: > Hi, > > Does LLVM have passes that do translations between GCC RTL and LLVM > SSA, RTL -> SSA and SSA -> RTL? Nope. There has been some talk about doing a Clang -> RTL or LLVM IR -> RTL backend, to allow using the GCC backend with the Clang frontend, but I'm not aware of any progress on this. You could ask on the

On Tue, Jun 22, 2010 at 1:53 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 22, 2010, at 10:29 AM, Jianzhou Zhao wrote: > >> Hi, >> >> Does LLVM have passes that do translations between GCC RTL and LLVM >> SSA, RTL -> SSA and SSA -> RTL? > > Nope.  There has been some talk about doing a Clang -> RTL or LLVM IR -> RTL backend, to

Hans Wennborg wrote: > I too have stumbled over this. > > Wouldn't it be a good idea to add a check for this to the function > verifier pass? No. This is a FAQ: http://llvm.org/docs/FAQ.html#callconvwrong Nick > > > Hans > > Anton Korobeynikov wrote: >> Hello >> >>> I naively though it would pick up the call convention from the declaration

On Thu, Dec 10, 2009 at 12:21 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Hans Wennborg wrote: >> I too have stumbled over this. >> >> Wouldn't it be a good idea to add a check for this to the function >> verifier pass? > > No. This is a FAQ: http://llvm.org/docs/FAQ.html#callconvwrong IMO you could move the cc to the type and still replace mismatched

Attached are updated LLVM-OCaml Bindings Tutorial from Chris Wailes. (http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-April/021804.html) We changed them to work with the latest APIs(LLVM2.6 and the latest LLVM from SVN). Does anyone know if there is any realistic project using LLVM-OCaml Bindings? How is the performance? Jianzhou -------------- next part -------------- A non-text attachment was