search for: refineabstracttypes

...equivalent of: > >> > >> %t1 = type opaque > >> %t2 = type void(%t1*) > >> > >> and you refine t1 -> t2, it should work. > > > > I'm not sure it will. %t1* is the "contained" type inside the > > FunctionType. > > RefineAbstractTypes expects the OldType (%t1 in this case) to be in > > the > > contained type set. Since a _pointer_ to %t1 is in the contained > > set, it > > doesn't see it. > > How is this any different than the struct case of {\2*} ? I don't know. All I know is when I call...

...aque > >>>> %t2 = type void(%t1*) > >>>> > >>>> and you refine t1 -> t2, it should work. > >>> > >>> I'm not sure it will. %t1* is the "contained" type inside the > >>> FunctionType. > >>> RefineAbstractTypes expects the OldType (%t1 in this case) to be in > >>> the > >>> contained type set. Since a _pointer_ to %t1 is in the contained > >>> set, it > >>> doesn't see it. > >> > >> How is this any different than the struct case of {\2...

...> >>>> %t1 = type opaque >>>> %t2 = type void(%t1*) >>>> >>>> and you refine t1 -> t2, it should work. >>> >>> I'm not sure it will. %t1* is the "contained" type inside the >>> FunctionType. >>> RefineAbstractTypes expects the OldType (%t1 in this case) to be in >>> the >>> contained type set. Since a _pointer_ to %t1 is in the contained >>> set, it >>> doesn't see it. >> >> How is this any different than the struct case of {\2*} ? > > I don't kno...

...> pointee types. > > What types are you starting out with? If you had the equivalent of: > > %t1 = type opaque > %t2 = type void(%t1*) > > and you refine t1 -> t2, it should work. I'm not sure it will. %t1* is the "contained" type inside the FunctionType. RefineAbstractTypes expects the OldType (%t1 in this case) to be in the contained type set. Since a _pointer_ to %t1 is in the contained set, it doesn't see it. -Dave

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 using varargs (opinions welcome). In a simpler C++

...are you starting out with? If you had the equivalent of: >> >> %t1 = type opaque >> %t2 = type void(%t1*) >> >> and you refine t1 -> t2, it should work. > > I'm not sure it will. %t1* is the "contained" type inside the > FunctionType. > RefineAbstractTypes expects the OldType (%t1 in this case) to be in > the > contained type set. Since a _pointer_ to %t1 is in the contained > set, it > doesn't see it. How is this any different than the struct case of {\2*} ? -Chris

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

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 ***

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

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

Hi, I am using current SVN and in the last week or so, something causing the following assertion failure has changed. void llvm::PATypeHolder::addRef(): Assertion `Ty && "Type Holder has a null type!"' failed. The corresponding stack trace is: #0 0x000000339ec332f5 in raise () from /lib64/libc.so.6 #1 0x000000339ec34b20 in abort () from /lib64/libc.so.6 #2

Le Thu, May 03, 2007 at 09:36:22AM -0700, Chris Lattner écrivait/wrote: > On Thu, 3 May 2007, Basile STARYNKEVITCH wrote: > > > > > FWIW, the latest gcc snapshot from yesterday gcc version 4.3.0 20070501 > > (experimental) fail to compile latest LLVM (with compile errors!). > > Please file an llvm bug report with these errors. It may be that we are > doing

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

Hi, Probably some of the leaks Valgrind reports are spurious, but the numbers seem to be significant enough to demand some attention: ==10132== LEAK SUMMARY: ==10132== definitely lost: 15,624 bytes in 558 blocks. ==10132== indirectly lost: 44,548 bytes in 1,591 blocks. ==10132== possibly lost: 37,576 bytes in 98 blocks. ==10132== still reachable: 1,336,876 bytes in 1,364 blocks.