[llvm-dev] C++ CreateConstGEP questions

[David Blaikie via llvm-dev]

Thanks David - that about sums it up.

I think my choice of GEP migration wasn't the best - leaving both versions
in and/or removing the old version but allowing null to be passed as a
silent fallback. In other cases I've been more rigorous about just changing
the API to require the extra type information (& making callers just
getPointeeType as an immediate solution, then pushing those calls up a
layer, etc, until I could get rid of them entirely). That made the
transition boundary clearer.

- David

On Tue, May 10, 2016 at 3:45 AM, David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/620a9a41/attachment.html>