similar to: [LLVMdev] RefineAbstractType

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 =

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

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

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

On Wednesday 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 > >>>>> (...))

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 Aug 27, 2012, at 10:15 PM, Chris Lattner <clattner at apple.com> wrote: > On Aug 27, 2012, at 12:58 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> On Mon, 27 Aug 2012 11:41:47 -0700 >> Dan Gohman <gohman at apple.com> wrote: >>> On Aug 24, 2012, at 10:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> >>>> On Wed, 22 Aug 2012

On Wed, Dec 12, 2012 at 8:38 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Tue, Dec 11, 2012 at 03:17:43AM -0800, Chandler Carruth wrote: >> As Joerg pointed out in IRC, 'y' is an lvalue, but we do not use it to >> access the object it designates, we only use it to compute the address, and >> thus restrict should have no bearing on it. That

Hi all, An oddity that has existed for a long time in the IR is that PointerType derives from SequentialType. Per subject I propose to make PointerType derive from Type for a couple of reasons: - Values of type PointerType are unlike the other SequentialTypes (arrays and vectors) in that they do not hold values of the element type. By moving PointerType we can unify certain aspects of how the

Hi - help! I have read through previous threads on the subject of 'byval' e.g. https://groups.google.com/forum/#!topicsearchin/llvm-dev/Exact$20meaning$20of$20byval/llvm-dev/cyRZyXcMCNI https://groups.google.com/forum/#!topicsearchin/llvm-dev/$20byval/llvm-dev/uk4uiK93jeM https://groups.google.com/forum/#!topicsearchin/llvm-dev/byval/llvm-dev/46Tv0lSRwBg and read through code

While checking for serialization/deserialization without using pointee types, I've come across a few test cases that crash at head, without my debugging assertions for accessing pointee types. One of them is test/Transforms/StripSymbols/2010-06-30-StripDebug.ll Its retainedTypes metadata points to a metadata array of a single null element. This crashes the dyn_cast (because it's not a

>>> Please add a generous block comment to >>> llvm/include/llvm/Bitcode/LLVMBitCodes.h above the new enum >>> explaining >>> what the difference is though. :) >> > > Should have said: > >> Should I take the same approach to the encoding of pointer types in >> the types table? PointerTypes are a bit easier. The code to write them

LLVM developers, I was wondering if the program would still be safe if I strip the byval attributes from the parameters in the entire bitcode. LLVM language reference manual states that "The attribute implies that a hidden copy of the pointee is made between the caller and the callee, so the callee is unable to modify the value in the callee. This attribute is only valid on LLVM pointer

Seems pretty plausible to me - my only question would be whether it's worth the churn to do this intermediate step before finishing off typeless pointers (granted, I've stalled out on that for nearly a year, admittedly - but good to have extra hands/incentives - there's still a fair bit of work to do though, so understandable if it might not be useful to block progress on other things