[LLVMdev] Convenience methods in ConstantExpr et al

[Talin]

On Mon, Jan 31, 2011 at 10:57 PM, Talin <viridia at gmail.com> wrote:

> I notice that there's a lot of inconsistency in the various LLVM classes
> with respect to convenience methods. Here's some examples:
>
> For creating GEPS, IRBuilder has:
>
>   CreateGEP (2 overloads)
>   CreateInBoundsGEP (2 overloads)
>   CreateConstGEP1_32
>   CreateConstInBoundsGEP1_32
>   CreateConstGEP2_32
>   CreateConstInBoundsGEP2_32
>   CreateConstGEP1_64
>   CreateConstInBoundsGEP1_64
>   CreateConstGEP2_64
>   CreateConstInBoundsGEP2_64
>   CreateStructGEP
>
> All of which are very useful. However, ConstExpression only has:
>
>   getGetElementPtr
>   getGetElementPtr
>   getInBoundsGetElementPtr
>   getInBoundsGetElementPtr
>
> It would be nice if ConstantExpr's GEP-building methods used the same
> naming convention and had the same convenience methods as IRBuilder. (In
> fact, the naming convention between IRBuilder and the various Constants.h
> classes desperately needs to be reconciled, a point which I am sure everyone
> is painfully aware of.)
>
> Another thing I'd like to see is for ConstantArray::get(),
> ConstantStruct::get() and ConstantVector::get() to have an overload that
> takes an iterator pair like IRBuilder's CreateGEP and CreateCall methods.
> Also useful for creating small structs would be overloads for
> ConstantStruct::get that took 1-4 arguments, instead of having to create a
> vector every time. Even better would be an "end with null" version, like
> StructType::get() does. These should be added to FunctionType::get() as
> well.
>

By the way, the reason I'm asking this is because I thought I might spend
some time adding the convenience methods myself - but if there is a plan
underway to fix up the APIs or resolve the incompatibilities with the naming
conventions I don't want to get in the way of that.


> --
> -- Talin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110202/4f19f8ef/attachment.html>