[LLVMdev] Convenience methods in ConstantExpr et al

Talin viridia at gmail.com
Wed Feb 2 19:27:07 PST 2011


On Wed, Feb 2, 2011 at 1:29 PM, Nick Lewycky <nicholas at mxc.ca> wrote:

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


I find that I call the static methods in ConstantExpr a *lot* without going
through IRBuilder - hundreds of times in my frontend. My language generates
a lot of static data - reflection information, trace tables for the garbage
collector, dispatch tables, runtime annotations, static object instances,
and so on. (In fact there's a special helper class "StructBuilder" that
automates a lot of the work of building constant structs, such as adding the
standard object header and so on.)

I guess what I'm asking is, would there be any *resistance* to adding
additional static members to ConstantExpr to make it more convenient to do
constant GEPs?

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


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


More information about the llvm-dev mailing list