similar to: RFC: PointerType should derive from Type rather than SequentialType

Thanks David. I ended up trying this over the weekend (see https://github.com/llvm-project/llvm-project/compare/ master...pcc:pointertype). It ended up being a net reduction in code size so seems like a useful cleanup even independent of the typeless pointer work, I'll see if I can send a patch to the list. FWIW I think this directly helps towards the migration because we would have a clearer

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

On Mon, Oct 31, 2016 at 1:43 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks David. I ended up trying this over the weekend (see > https://github.com/llvm-project/llvm-project/compare/master...pcc:pointertype). > It ended up being a net reduction in code size so seems like a useful > cleanup even independent of the typeless pointer work, I'll see if I can >

Hi, I was playing with the Constant::getAllOnesValue() method and found that it doesn't handlesPointerTypes correctly. When receiving a "i32*" argument, it was returning with some big integer vector, such as <12113216 x i32>. When you call this method passing a PointerType, the following code is executed: 00152 VectorType *VTy = cast<VectorType>(Ty);00153 return

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

John, thanks for you answer! But as far as I know LLVM doesn't provide any interface for finding the pointee of a pointer directly, so i have to process a multi-level pointer i need to write my own function to check pointers level by level, is that right? On Fri, Jul 17, 2015 at 1:47 PM, John Criswell <jtcriswel at gmail.com> wrote: > On 7/17/15 12:38 PM, Shen Liu wrote: > >

Hi John, I’d like to address some points in your message. > Practically speaking, this is going to break every out-of-tree frontend, backend, or optimization pass that supports SIMD types. My understanding is that the policy in LLVM development is that we do not let considerations for downstream and out-of-tree codebases affect the pace of development. The C++ API is explicitly unstable.

John, thanks for your helpful advice. My ultimate goal is to construct a full instruction-level program dependence graph for a given IR file. The hard point is how to establish the correct data dependence edges when some function arguments are multi-level pointers. To solve this problem I hope to check the point-to level for each pointer variable. I think the data dependence through pointers can

On Sun, Apr 16, 2017 at 2:34 AM James Courtier-Dutton via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > Did this work ever get done? There was a long thread about it back in 2015. > > I wish to use IRBuilder. > Is there any documentation? > How do I use the singular pointer type in GEP, LOAD, STORE instructions? > Sorry, no, the work is not complete - for

Hello, I'm wondering if it's possible to dereference a PointerType. I have an AllocaInst and although I can find the number of elements allocated, (using Instruction::getOperand(0)), I can't find a way to get the size of each element. What I'd like to do is: AllocaInst *alloca; PointerType *ptr_type = dynamic_cast<PointerType*>(alloca); assert(ptr_type); Type

On 10/24/2016 1:07 PM, Peter Collingbourne via llvm-dev wrote: > On Mon, Oct 10, 2016 at 8:12 PM, Peter Collingbourne <peter at pcc.me.uk > <mailto:peter at pcc.me.uk>> wrote: > > The specific change I have in mind is to allow !range metadata on > GlobalObjects. This would > be similar to existing !range metadata, but it would apply to the >

On Dec 16, 2007, at 10:22 PM, Anton Korobeynikov wrote: > Christopher, > >> The API for getting PointerType objects has just changed to make >> Embedded C address space information explicit. The old semantics of >> PointerType::get() now apply to PointerType::getUnqual(), which >> returns a pointer in the generic address space. PointerType::get() >> now

Christopher, > The API for getting PointerType objects has just changed to make > Embedded C address space information explicit. The old semantics of > PointerType::get() now apply to PointerType::getUnqual(), which > returns a pointer in the generic address space. PointerType::get() now > requires both a type and an address space. What is the reason of such change? -- With best

The API for getting PointerType objects has just changed to make Embedded C address space information explicit. The old semantics of PointerType::get() now apply to PointerType::getUnqual(), which returns a pointer in the generic address space. PointerType::get() now requires both a type and an address space. The clang, llvm-gcc-4.0, and llvm-gcc-4.2, and internal llvm projects have all

2009/10/20 Daniel Waterworth <da.waterworth at googlemail.com> > Hello, > > I'm wondering if it's possible to dereference a PointerType. I have an > AllocaInst and although I can find the number of elements allocated, (using > Instruction::getOperand(0)), I can't find a way to get the size of each > element. What I'd like to do is: > > AllocaInst

On Wed, Mar 16, 2016 at 11:00 AM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > David, > > Could you give us an update on the status of typeless pointer work? How > much work is left and when you think it might be ready? > It's a bit of an onion peel, really - since it will eventually involve generalizing/fixing every optimization that's currently leaning on typed

On 2007-12-17, at 00:31, Christopher Lamb wrote: > The API for getting PointerType objects has just changed to make > Embedded C address space information explicit. The old semantics of > PointerType::get() now apply to PointerType::getUnqual(), which > returns a pointer in the generic address space. PointerType::get() > now requires both a type and an address space. >

Daniel Waterworth <da.waterworth at googlemail.com> writes: [snip] Use the getElementType method of PointerType. >> size_t size; >> if (isa<PointerType>(allocated_type)) { >> size = sizeof(void*) * 8; >> } else { >> size = allocated_type->getPrimitiveSizeInBits(); >> } >> // size now equals the size (in bits) of the type allocated

I don't know enough about the tradeoff for 1, but 2 seems like a bandaid for something that is not a correctness issue neither a regression. I'm not sure it justifies "bandaid patches" while there is a clear path forward, i.e. typeless pointers, unless there is an acknowledgement that typeless pointers won't be there before a couple of years. -- Mehdi > On Mar 22, 2016,

Would it be possible to keep get() unchanged, with a default behaviour, plus a warning? Otherwise everybody (assuming everybody gets type void*) will have to update their LLVM passes, and either maintain two versions of the passes or require their clients to use a certain LLVM version. Then passes could be "address-space-safe" or not. If the default parameter value for get() could