[LLVMdev] Convenience methods in ConstantExpr et al

[Nick Lewycky]

Talin wrote:
> On Mon, Jan 31, 2011 at 10:57 PM, Talin <viridia at gmail.com
> <mailto: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.)

It's a matter of layering. IRBuilder will call into ConstantExpr as 
needed; the ConstantExpr API is at the same level as the 
llvm::Instruction hierarchy itself.

>     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.

Yep!

Nick

> 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.