search for: pointertypes

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

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

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

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

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

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

Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =

Óscar Fuentes wrote: > 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(); >>>

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 folks, TableGen provides sufficiently rich syntax for expressing target instruction set. Nevertheless, when I wrote the PTX backend, I observed that some redundancy in TableGen can be further eliminated through macro expansion of for-loops. The semantics of a for-loop is expanding the for-loop body, and so it is equivalent to manually unroll the loop (see example #1). I believe the for-loop

It may not be the best way to do what I'm trying to do, but it's not useless and bogus. Consider the following: %1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type i32* and ; the size of that is sizeof(void *) bytes Having said that I am looking at the target data getTypeAllocSize method. Daniel 2009/10/20 Duncan Sands <baldrick at

On Dec 17, 2007, at 1:22 AM, Torvald Riegel wrote: > 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. AFAIK API

Thanks Nick, Unfortunately, that is indeed what I asked for but not what I really am looking for. My naive approach is to store symbol table entries as Value* objects so I can allocate global variables and alloca variables and place them into the symbol table and the rest of the code didn't need to know which kind they were, in general. Loads and Stores of these types (as well as other

Mon Ping, Thanks for the tip, but I can't for the life of me seem to get the Value from a StoreSDNode. From looking at the SelectionDAGNodes header file, the only class that has the getValue function call is SrcValueSDNode that returns a Value type. The only class that has getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode is what I want and when I try to cast the

Daniel Waterworth <da.waterworth at googlemail.com> writes: > It may not be the best way to do what I'm trying to do, but it's not useless > and bogus. Consider the following: > > %1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type i32* > and > ; the size of that is sizeof(void *) bytes What Duncan says is that any valid