llvm dev - Feb 2011 - [LLVMdev] Convenience methods in ConstantExpr et al

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.

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

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>

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.