On Wed, Feb 2, 2011 at 1:29 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca">nicholas@mxc.ca</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Talin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Mon, Jan 31, 2011 at 10:57 PM, Talin <<a href="mailto:viridia@gmail.com" target="_blank">viridia@gmail.com</a><br></div><div><div></div><div class="h5">
<mailto:<a href="mailto:viridia@gmail.com" target="_blank">viridia@gmail.com</a>>> wrote:<br>
<br>
I notice that there's a lot of inconsistency in the various LLVM<br>
classes with respect to convenience methods. Here's some examples:<br>
<br>
For creating GEPS, IRBuilder has:<br>
<br>
CreateGEP (2 overloads)<br>
CreateInBoundsGEP (2 overloads)<br>
CreateConstGEP1_32<br>
CreateConstInBoundsGEP1_32<br>
CreateConstGEP2_32<br>
CreateConstInBoundsGEP2_32<br>
CreateConstGEP1_64<br>
CreateConstInBoundsGEP1_64<br>
CreateConstGEP2_64<br>
CreateConstInBoundsGEP2_64<br>
CreateStructGEP<br>
<br>
All of which are very useful. However, ConstExpression only has:<br>
<br>
getGetElementPtr<br>
getGetElementPtr<br>
getInBoundsGetElementPtr<br>
getInBoundsGetElementPtr<br>
<br>
It would be nice if ConstantExpr's GEP-building methods used the<br>
same naming convention and had the same convenience methods as<br>
IRBuilder. (In fact, the naming convention between IRBuilder and the<br>
various Constants.h classes desperately needs to be reconciled, a<br>
point which I am sure everyone is painfully aware of.)<br>
</div></div></blockquote>
<br>
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.</blockquote><div><br></div><div>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.)</div>
<div><br></div><div>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?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another thing I'd like to see is for ConstantArray::get(),<br>
ConstantStruct::get() and ConstantVector::get() to have an overload<br>
that takes an iterator pair like IRBuilder's CreateGEP and<br>
CreateCall methods. Also useful for creating small structs would be<br>
overloads for ConstantStruct::get that took 1-4 arguments, instead<br>
of having to create a vector every time. Even better would be an<br>
"end with null" version, like StructType::get() does. These should<br>
be added to FunctionType::get() as well.<br>
</blockquote>
<br></div>
Yep!<br><font color="#888888">
<br>
Nick</font><div><div></div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
By the way, the reason I'm asking this is because I thought I might<br>
spend some time adding the convenience methods myself - but if there is<br>
a plan underway to fix up the APIs or resolve the incompatibilities with<br>
the naming conventions I don't want to get in the way of that.<br>
</blockquote>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>