[llvm-dev] C++ CreateConstGEP questions

[David Chisnall via llvm-dev]

On 9 May 2016, at 21:11, Larry Gritz via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> There are two C++ signatures for CreateConstGEP1_32:
> 
>    Value * CreateConstGEP1_32 (Value *Ptr, unsigned Idx0, const Twine &Name="")
>    Value * CreateConstGEP1_32 (Type *Ty, Value *Ptr, unsigned Idx0, const Twine &Name="")
> 
> I'm assuming that this means that the caller can supply the expected type, and get error checking or casting? Or choose to not supply the type and get whatever they get?
> 
> But for CreateConstGEP2_32, there is only the variety with the type supplied:
> 
>    Value * CreateConstGEP2_32 (Type *Ty, Value *Ptr, unsigned Idx0, unsigned Idx1, const Twine &Name="")
> 
> For CreateConstGEP2_64, there is only the version with no Type supplied:
> 
>    Value * CreateConstGEP2_64 (Value *Ptr, uint64_t Idx0, uint64_t Idx1, const Twine &Name="")
> 
> Same for CreateConstGEP1_64 -- no Type* parameter.
> 
> Can anybody offer insight into the strange lack of symmetry here? Why does GEP2_32 require the type, but GEP1_64 and GEP2_64 doesn't allow it all, but GEP1_32 has both varieties?
> 
> Is it always safe to pass nullptr as the type?

This is likely fallout from the in-progress typeless pointer work.  The goal is to remove the pointee type from the pointer, so i8*, i64*, %foo* and so on will all simply be ptr (optionally qualified with an address space).  As an intermediate step to this, GEPs now must be associated with the pointee type because eventually that information will no longer be available from the type.

If you want your code to be easy to migrate to future LLVM versions, please use the version that takes an explicit type parameter and provide the type (by some mechanism other than pointee->getType()).  In the short term, you will get some type checking (an assertion failure if the types don’t match).  Eventually, this will be the only API.

I suspect that the _64 versions were simply missed in the patch and the _32 versions without the type parameter were not GC’d to provide a smoother migration path.  They should ideally be marked with a deprecated attribute, as they are going to stop working (and become impossible to implement) at some point.  

Passing nullptr here ought to trigger an assertion failure, so probably not a sensible thing to do.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3719 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/f1f0375e/attachment.bin>