[llvm-dev] C++ CreateConstGEP questions
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Tue May 10 11:41:28 PDT 2016
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.
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>
> > There are two C++ signatures for CreateConstGEP1_32:
> > Value * CreateConstGEP1_32 (Value *Ptr, unsigned Idx0, const Twine
> > 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
> > 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev