Displaying 20 results from an estimated 4000 matches similar to: "RFC: PointerType should derive from Type rather than SequentialType"
2016 Oct 31
2
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
2016 Oct 31
0
RFC: PointerType should derive from Type rather than SequentialType
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
2016 Oct 31
0
RFC: PointerType should derive from Type rather than SequentialType
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
>
2012 Jun 03
1
[LLVMdev] Constant::getAllOnesValue(): expected behaviour or bug?
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
2007 Nov 25
2
[LLVMdev] C embedded extensions and LLVM
>>> 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
2015 Jul 17
2
[LLVMdev] How can i differentiate pointer type int 32* from int 32** ?
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:
>
>
2020 May 21
3
[RFC] Refactor class hierarchy of VectorType in the IR
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.
2015 Jul 18
4
[LLVMdev] How can i differentiate pointer type int 32* from int 32** ?
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
2017 Apr 16
2
[LLVMdev] Moving towards a singular pointer type
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
2009 Oct 20
3
[LLVMdev] Dereference PointerType?
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
2016 Oct 24
3
RFC: Absolute or "fixed address" symbols as immediate operands
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
>
2007 Dec 17
0
[LLVMdev] PointerType API Change
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
2007 Dec 17
3
[LLVMdev] PointerType API Change
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
2007 Dec 17
3
[LLVMdev] PointerType API Change
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 Oct 20
0
[LLVMdev] Dereference PointerType?
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
2016 Mar 16
3
RFC: A change in InstCombine canonical form
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
2007 Dec 17
0
[LLVMdev] PointerType API Change
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.
>
2009 Oct 20
2
[LLVMdev] Dereference PointerType?
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
2016 Mar 22
2
RFC: A change in InstCombine canonical form
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,
2007 Dec 17
2
[LLVMdev] PointerType API Change
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