Method GetElementPtrInBounds
GetElementPtrInBounds(Value, IEnumerable<Value>)
Creates a Value that accesses an element of a type referenced by a pointer
Declaration
[Obsolete("Use overload that takes a pointer type and opaque pointer")]
public Value GetElementPtrInBounds(Value pointer, IEnumerable<Value> args)
Parameters
[Obsolete("Use overload that takes a pointer type and opaque pointer")]
public Value GetElementPtrInBounds(Value pointer, IEnumerable<Value> args)| Value | pointer | pointer to get an element from |
| IEnumerable<Value> | args | additional indices for computing the resulting pointer |
Returns
| Value | Value for the member access. This is a Value as LLVM may optimize the expression to a ConstantExpression if it can so the actual type of the result may be ConstantExpression or GetElementPtr. Note that |
Remarks
For details on GetElementPointer (GEP) see The Often Misunderstood GEP Instruction. The basic gist is that the GEP instruction does not access memory, it only computes a pointer offset from a base. A common confusion is around the first index and what it means. For C and C++ programmers an expression like pFoo->bar seems to only have a single offset or index. However, that is only syntactic sugar where the compiler implicitly hides the first index. That is, there is no difference between pFoo[0].bar and pFoo->bar except that the former makes the first index explicit. LLVM requires an explicit first index, even if it is zero, in order to properly compute the offset for a given element in an aggregate type.
GetElementPtrInBounds(ITypeRef, Value, IEnumerable<Value>)
Creates a Value that accesses an element of a type referenced by a pointer
Declaration
public Value GetElementPtrInBounds(ITypeRef type, Value pointer, IEnumerable<Value> args)
Parameters
public Value GetElementPtrInBounds(ITypeRef type, Value pointer, IEnumerable<Value> args)| ITypeRef | type | Base pointer type |
| Value | pointer | opaque pointer to get an element from |
| IEnumerable<Value> | args | additional indices for computing the resulting pointer |
Returns
| Value | Value for the member access. This is a Value as LLVM may optimize the expression to a ConstantExpression if it can so the actual type of the result may be ConstantExpression or GetElementPtr. Note that |
Remarks
For details on GetElementPointer (GEP) see The Often Misunderstood GEP Instruction. The basic gist is that the GEP instruction does not access memory, it only computes a pointer offset from a base. A common confusion is around the first index and what it means. For C and C++ programmers an expression like pFoo->bar seems to only have a single offset or index. However, that is only syntactic sugar where the compiler implicitly hides the first index. That is, there is no difference between pFoo[0].bar and pFoo->bar except that the former makes the first index explicit. LLVM requires an explicit first index, even if it is zero, in order to properly compute the offset for a given element in an aggregate type.
GetElementPtrInBounds(Value, Value[])
Creates a Value that accesses an element of a type referenced by a pointer
Declaration
[Obsolete("Use overload that accepts base pointer type and na opaque pointer")]
public Value GetElementPtrInBounds(Value pointer, params Value[] args)
Parameters
[Obsolete("Use overload that accepts base pointer type and na opaque pointer")]
public Value GetElementPtrInBounds(Value pointer, params Value[] args)| Value | pointer | pointer to get an element from |
| Value[] | args | additional indices for computing the resulting pointer |
Returns
| Value | Value for the member access. This is a Value as LLVM may optimize the expression to a ConstantExpression if it can so the actual type of the result may be ConstantExpression or GetElementPtr. Note that |
Remarks
For details on GetElementPointer (GEP) see The Often Misunderstood GEP Instruction. The basic gist is that the GEP instruction does not access memory, it only computes a pointer offset from a base. A common confusion is around the first index and what it means. For C and C++ programmers an expression like pFoo->bar seems to only have a single offset or index. However that is only syntactic sugar where the compiler implicitly hides the first index. That is, there is no difference between pFoo[0].bar and pFoo->bar except that the former makes the first index explicit. LLVM requires an explicit first index, even if it is zero, in order to properly compute the offset for a given element in an aggregate type.
GetElementPtrInBounds(ITypeRef, Value, Value[])
Creates a Value that accesses an element of a type referenced by a pointer
Declaration
public Value GetElementPtrInBounds(ITypeRef type, Value pointer, params Value[] args)
Parameters
public Value GetElementPtrInBounds(ITypeRef type, Value pointer, params Value[] args)| ITypeRef | type | Base pointer type |
| Value | pointer | opaque pointer to get an element from |
| Value[] | args | additional indices for computing the resulting pointer |
Returns
| Value | Value for the member access. This is a Value as LLVM may optimize the expression to a ConstantExpression if it can so the actual type of the result may be ConstantExpression or GetElementPtr. Note that |
Remarks
For details on GetElementPointer (GEP) see The Often Misunderstood GEP Instruction. The basic gist is that the GEP instruction does not access memory, it only computes a pointer offset from a base. A common confusion is around the first index and what it means. For C and C++ programmers an expression like pFoo->bar seems to only have a single offset or index. However that is only syntactic sugar where the compiler implicitly hides the first index. That is, there is no difference between pFoo[0].bar and pFoo->bar except that the former makes the first index explicit. LLVM requires an explicit first index, even if it is zero, in order to properly compute the offset for a given element in an aggregate type.