search for: refineabstracttype

On Wednesday 12 November 2008 18:58, Chris Lattner wrote: > On Nov 12, 2008, at 3:37 PM, David Greene wrote: > >>> Unfortunately, calling FunctionType::refineAbstractType(opaque, void > >>> (...)) > >>> doesn't work because RefineAbstractType doesn't recurse down into > >>> the > >>> pointee types. > >> > >> What types are you starting out with? If you had the equivalent of: > >> &gt...

...nesday 12 November 2008 19:13, Chris Lattner wrote: > On Nov 12, 2008, at 5:07 PM, David Greene wrote: > > On Wednesday 12 November 2008 18:58, Chris Lattner wrote: > >> On Nov 12, 2008, at 3:37 PM, David Greene wrote: > >>>>> Unfortunately, calling FunctionType::refineAbstractType(opaque, > >>>>> void > >>>>> (...)) > >>>>> doesn't work because RefineAbstractType doesn't recurse down into > >>>>> the > >>>>> pointee types. > >>>> > >>>> What types a...

On Nov 12, 2008, at 5:07 PM, David Greene wrote: > On Wednesday 12 November 2008 18:58, Chris Lattner wrote: >> On Nov 12, 2008, at 3:37 PM, David Greene wrote: >>>>> Unfortunately, calling FunctionType::refineAbstractType(opaque, >>>>> void >>>>> (...)) >>>>> doesn't work because RefineAbstractType doesn't recurse down into >>>>> the >>>>> pointee types. >>>> >>>> What types are you starting out with? If you...

On Wednesday 12 November 2008 17:29, Chris Lattner wrote: > In fact, I strongly suspect that RefineAbstractType doesn't work if > you give it something that isn't Opaque. I'd recommend only using it > on Opaque, not random abstract types. Ok. > Sure, LLVM is more general than C. In LLVM, you can have a pointer > that points to itself, for example: > > %t = type %t* > >...

Is there some reason that RefineAbstractType doesn't recurse down DerivedTypes and further resolve abstract types? In Fortran it is possible to have a routine that takes a function pointer to a routine with the same signature. This is not possible to express in C/C++. I'm not sure it's possible to express in LLVM either without...

On Nov 12, 2008, at 3:37 PM, David Greene wrote: >>> Unfortunately, calling FunctionType::refineAbstractType(opaque, void >>> (...)) >>> doesn't work because RefineAbstractType doesn't recurse down into >>> the >>> pointee types. >> >> What types are you starting out with? If you had the equivalent of: >> >> %t1 = type opaque >>...

On Nov 12, 2008, at 2:59 PM, David Greene wrote: > Is there some reason that RefineAbstractType doesn't recurse down > DerivedTypes > and further resolve abstract types? Because that would resolve two different types. RefineAbstractType just refines the one type you request, and further uniques types based on it. In fact, I strongly suspect that RefineAbstractType doesn'...

On Nov 13, 2008, at 2:35 PM, David Greene wrote: >> t1->refineAbstractType(t2) > > Oh, I see. > > Then what's the purpose of PointerType::refineAbstractType, > FunctionType::refineAbstractType, etc.? They are "internal" implementation details of the refinement system. -Chris

On Wednesday 12 November 2008 19:13, Chris Lattner wrote: > You shouldn't be refining the pointer, you should use: > > t1->refineAbstractType(t2) Ok, I tried this and I get further. But the type system seems to have trouble when refining multiple types and those types resolve to the same thing. I turned on DEBUG_MERGE_TYPES to illustrate: *** First function type *** TypeMap<>::add table contents: 1. 0x3a4e6a0 i32 * Derived new...

I'm working on a personal project which involves lowering a superset of LLVM to "vanilla" LLVM. Part of this involves rewriting types. I'm working off of the 2.6 code base, so this may have been addressed in a bug fix. I'm having trouble with refineAbstractType and recursive types. Specifically, I'm creating opaque types to serve as placeholders for the final recursive type, then using refineAbstractType to replace the placeholders with the actual type. However, pointers to the opaque type aren't being replaced with pointers to the actual typ...

On Thursday 13 November 2008 18:27, David Greene wrote: > On Wednesday 12 November 2008 19:13, Chris Lattner wrote: > > You shouldn't be refining the pointer, you should use: > > > > t1->refineAbstractType(t2) > > Ok, I tried this and I get further. But the type system seems to have > trouble when refining multiple types and those types resolve to the same > thing. I turned on DEBUG_MERGE_TYPES to illustrate: Attached is some code that illustrates what I think is the problem. Compile w...

...eHolder::PATypeHolder(const struct llvm::Type *) (this=0x1d7a740, ty=0x0) at /home/maurice/installation/llvm-dev/include/llvm/AbstractTypeUser.h:143 #5 0x00000000015828d8 in llvm::DerivedType::dropAllTypeUses (this=0x1d777d0) at Type.cpp:469 #6 0x0000000001584b1f in llvm::DerivedType::unlockedRefineAbstractTypeTo (this=0x1d777d0, NewType=0x1d5b050) at Type.cpp:1454 #7 0x000000000158b84c in llvm::TypeMap<llvm::PointerValType, llvm::PointerType>::RefineAbstractType (this=0x1d5afe0, Ty=0x1d777d0, OldType=0x1d77780, NewType=0x1d54190) at Type.cpp:884 #8 0x0000000001584fe2 in llvm::PointerType::ref...

...ning: type qualifiers ignored on function return type /usr/src/Lang/llvm/include/llvm/ADT/APInt.h:1047: warning: type qualifiers ignored on function return type In file included from APInt.cpp:17: /usr/src/Lang/llvm/include/llvm/DerivedTypes.h: In member function 'virtual void llvm::OpaqueType::refineAbstractType(const llvm::DerivedType*, const llvm::Type*)': /usr/src/Lang/llvm/include/llvm/DerivedTypes.h:412: error: 'abort' was not declared in this scope /usr/src/Lang/llvm/include/llvm/DerivedTypes.h: In member function 'virtual void llvm::OpaqueType::typeBecameConcrete(const llvm::DerivedT...

On Thu, 3 May 2007, Basile STARYNKEVITCH wrote: > > What version of g++ is usable to compile the latest LLVM CVS snapshot on a > Linux/x86-64 (AMD64) Debian/ Sid or Etch plateform? Please look here: http://llvm.org/docs/GettingStarted.html#brokengcc I'd suggest late versions of GCC 4.0.x. The 4.1 series has had numerous problems compiling LLVM on x86-64, though some people have

Hello All, What version of g++ is usable to compile the latest LLVM CVS snapshot on a Linux/x86-64 (AMD64) Debian/ Sid or Etch plateform? What compiler do LLVM dzevelopers use to compile LLVM on Linux/X86-64 systems? IKt seems that most versions of g++ fail to compile LLVM and that some others compile it wrongly (producing buggy code)? Why can't g++-4.1 be used? FWIW, the latest gcc

...in loss record 15 of 33 ==10132== at 0x401C7F0: operator new(unsigned) (vg_replace_malloc.c:164) ==10132== by 0x83F39E5: llvm::OpaqueType::get() (DerivedTypes.h:363) ==10132== by 0x84B5197: llvm::DerivedType::dropAllTypeUses() ( Type.cpp :481) ==10132== by 0x84B69F6: llvm::DerivedType::refineAbstractTypeTo(llvm::Type const*) (Type.cpp:1288) ==10132== by 0x852D604: llvm::TypeMap<llvm::PointerValType, llvm::PointerType>::RefineAbstractType(llvm::PointerType*, llvm::DerivedType const*, llvm::Type const*) ( Type.cpp:857) ==10132== by 0x84B6CC6: llvm::PointerType::refineAbstractType(llvm::De...