llvm dev - Jul 2009 - [LLVMdev] RFC: Constant Creation API

So, as you all probably noticed, the APIs for creating constants have  
been moved (or in a specific cases, are about to be moved) from static  
methods on Constant to instance methods on LLVMContext.

However, as was recently pointed out on llvm-commits and on IRC, this  
is no longer strictly necessary.  Because types have contexts, all of  
the constant subclasses could be friended to LLVMContext, and then put  
the work of uniquing by accessing the context off of the type.

There are obviously some pros and to both approaches.  Going back to  
the old-style increases compatibility with 2.5, and breaks up the  
massive LLVMContext class.  On the downside, it would cause massive  
thrashing on TOT, because I will have to revert about two weeks worth  
of commits in widely dispersed parts of the tree, and because a number  
of clients have already switched to the new TOT API.

Any comments and/or opinions on this decision are welcome.

--Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2620 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090723/cbd2a78c/attachment.bin>

On Jul 23, 2009, at 7:35 PM, Owen Anderson wrote:
> So, as you all probably noticed, the APIs for creating constants  
> have been moved (or in a specific cases, are about to be moved) from  
> static methods on Constant to instance methods on LLVMContext.
>
> However, as was recently pointed out on llvm-commits and on IRC,  
> this is no longer strictly necessary.  Because types have contexts,  
> all of the constant subclasses could be friended to LLVMContext, and  
> then put the work of uniquing by accessing the context off of the  
> type.
>
> There are obviously some pros and to both approaches.  Going back to  
> the old-style increases compatibility with 2.5, and breaks up the  
> massive LLVMContext class.  On the downside, it would cause massive  
> thrashing on TOT, because I will have to revert about two weeks  
> worth of commits in widely dispersed parts of the tree, and because  
> a number of clients have already switched to the new TOT API.
Unless there is a good reason not to, I think that sticking to the  
LLVM 2.5-style of APIs makes sense.

-Chris

On Thu, Jul 23, 2009 at 7:35 PM, Owen Anderson<resistor at mac.com>
wrote:
> So, as you all probably noticed, the APIs for creating constants have been
> moved (or in a specific cases, are about to be moved) from static methods
on
> Constant to instance methods on LLVMContext.
>
> However, as was recently pointed out on llvm-commits and on IRC, this is no
> longer strictly necessary.  Because types have contexts, all of the
constant
> subclasses could be friended to LLVMContext, and then put the work of
> uniquing by accessing the context off of the type.
>
> There are obviously some pros and to both approaches.  Going back to the
> old-style increases compatibility with 2.5, and breaks up the massive
> LLVMContext class.  On the downside, it would cause massive thrashing on
> TOT, because I will have to revert about two weeks worth of commits in
> widely dispersed parts of the tree, and because a number of clients have
> already switched to the new TOT API.
>
> Any comments and/or opinions on this decision are welcome.
This also works for several of the Type classes, since many of them
take another type in their constructors. Functions, arrays, pointers,
vectors, and all structs except the empty one can pull the Context out
of one of their nested types. On the other hand, consistency may argue
for putting all type creators in one place.

Jeffrey

Chris Lattner wrote:
> On Jul 23, 2009, at 7:35 PM, Owen Anderson wrote:
>   
>
> Unless there is a good reason not to, I think that sticking to the  
> LLVM 2.5-style of APIs makes sense.
>   
Oh no! :) Can't you keep both APIs?

Nicolas
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Chris Lattner skrev:
> Unless there is a good reason not to, I think that sticking to the  
> LLVM 2.5-style of APIs makes sense.
>
> -Chris

Yes, please!

/Another api-in-flux-victim

Hi,

1 vote in favour of sticking with the 2.5 API

Mark.

Owen Anderson wrote:
> So, as you all probably noticed, the APIs for creating constants have 
> been moved (or in a specific cases, are about to be moved) from static 
> methods on Constant to instance methods on LLVMContext.
> 
> However, as was recently pointed out on llvm-commits and on IRC, this is 
> no longer strictly necessary.  Because types have contexts, all of the 
> constant subclasses could be friended to LLVMContext, and then put the 
> work of uniquing by accessing the context off of the type.
> 
> There are obviously some pros and to both approaches.  Going back to the 
> old-style increases compatibility with 2.5, and breaks up the massive 
> LLVMContext class.  On the downside, it would cause massive thrashing on 
> TOT, because I will have to revert about two weeks worth of commits in 
> widely dispersed parts of the tree, and because a number of clients have 
> already switched to the new TOT API.
> 
> Any comments and/or opinions on this decision are welcome.
> 
> --Owen
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

I hate to say it (because I already made the changes), but keeping 
compatibility with 2.5 is a good thing.

-Rich

Owen Anderson wrote:
> So, as you all probably noticed, the APIs for creating constants have 
> been moved (or in a specific cases, are about to be moved) from static 
> methods on Constant to instance methods on LLVMContext.
> 
> However, as was recently pointed out on llvm-commits and on IRC, this is 
> no longer strictly necessary.  Because types have contexts, all of the 
> constant subclasses could be friended to LLVMContext, and then put the 
> work of uniquing by accessing the context off of the type.
> 
> There are obviously some pros and to both approaches.  Going back to the 
> old-style increases compatibility with 2.5, and breaks up the massive 
> LLVMContext class.  On the downside, it would cause massive thrashing on 
> TOT, because I will have to revert about two weeks worth of commits in 
> widely dispersed parts of the tree, and because a number of clients have 
> already switched to the new TOT API.
> 
> Any comments and/or opinions on this decision are welcome.
> 
> --Owen
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Yeah, for us who have already made the changes, this is kinda bitter sweet.

Maurice

On Fri, Jul 24, 2009 at 2:08 PM, Richard Pennington <rich at
pennware.com>wrote:
> I hate to say it (because I already made the changes), but keeping
> compatibility with 2.5 is a good thing.
>
> -Rich
>
> Owen Anderson wrote:
> > So, as you all probably noticed, the APIs for creating constants have
> > been moved (or in a specific cases, are about to be moved) from static
> > methods on Constant to instance methods on LLVMContext.
> >
> > However, as was recently pointed out on llvm-commits and on IRC, this
is
> > no longer strictly necessary.  Because types have contexts, all of the
> > constant subclasses could be friended to LLVMContext, and then put the
> > work of uniquing by accessing the context off of the type.
> >
> > There are obviously some pros and to both approaches.  Going back to
the
> > old-style increases compatibility with 2.5, and breaks up the massive
> > LLVMContext class.  On the downside, it would cause massive thrashing
on
> > TOT, because I will have to revert about two weeks worth of commits in
> > widely dispersed parts of the tree, and because a number of clients
have
> > already switched to the new TOT API.
> >
> > Any comments and/or opinions on this decision are welcome.
> >
> > --Owen
> >
> >
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090724/9d81df19/attachment.html>

On Jul 23, 2009, at 11:56 PM, Jeffrey Yasskin wrote:
> On Thu, Jul 23, 2009 at 7:35 PM, Owen Anderson<resistor at mac.com>  
> wrote:
>> So, as you all probably noticed, the APIs for creating constants  
>> have been
>> moved (or in a specific cases, are about to be moved) from static  
>> methods on
>> Constant to instance methods on LLVMContext.
>>
>> However, as was recently pointed out on llvm-commits and on IRC,  
>> this is no
>> longer strictly necessary.  Because types have contexts, all of the  
>> constant
>> subclasses could be friended to LLVMContext, and then put the work of
>> uniquing by accessing the context off of the type.
>>
>> There are obviously some pros and to both approaches.  Going back  
>> to the
>> old-style increases compatibility with 2.5, and breaks up the massive
>> LLVMContext class.  On the downside, it would cause massive  
>> thrashing on
>> TOT, because I will have to revert about two weeks worth of commits  
>> in
>> widely dispersed parts of the tree, and because a number of clients  
>> have
>> already switched to the new TOT API.
>>
>> Any comments and/or opinions on this decision are welcome.
>
> This also works for several of the Type classes, since many of them
> take another type in their constructors. Functions, arrays, pointers,
> vectors, and all structs except the empty one can pull the Context out
> of one of their nested types. On the other hand, consistency may argue
> for putting all type creators in one place.
The ones that don't can be static functions on the type class that  
take a context.  For example, Type::Int32Ty needs to become a function  
that takes a context at some point.

-Chris

If the 2.5 APIs are okay, then I also vote for sticking with them.

-bw

On Fri, Jul 24, 2009 at 4:44 AM, Mark Shannon<marks at dcs.gla.ac.uk>
wrote:
> Hi,
>
> 1 vote in favour of sticking with the 2.5 API
>
> Mark.
>
> Owen Anderson wrote:
>> So, as you all probably noticed, the APIs for creating constants have
>> been moved (or in a specific cases, are about to be moved) from static
>> methods on Constant to instance methods on LLVMContext.
>>
>> However, as was recently pointed out on llvm-commits and on IRC, this
is
>> no longer strictly necessary.  Because types have contexts, all of the
>> constant subclasses could be friended to LLVMContext, and then put the
>> work of uniquing by accessing the context off of the type.
>>
>> There are obviously some pros and to both approaches.  Going back to
the
>> old-style increases compatibility with 2.5, and breaks up the massive
>> LLVMContext class.  On the downside, it would cause massive thrashing
on
>> TOT, because I will have to revert about two weeks worth of commits in
>> widely dispersed parts of the tree, and because a number of clients
have
>> already switched to the new TOT API.
>>
>> Any comments and/or opinions on this decision are welcome.
>>
>> --Owen
>>
>>
>>
------------------------------------------------------------------------
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Hi Owen,

What if I want to have global llvm::Type's, that can be used by many 
LLVMContext's. For example, I'd like to have one LLVMContext per 
function, and  be able to create constants that belong to the context 
but using a global, shared amongst LLVMContext's, llvm::Type.

I know that's not doable right now, but aren't we losing this 
possibility if we move back to the old static functions?

Thanks,
Nicolas

Owen Anderson wrote:
> So, as you all probably noticed, the APIs for creating constants have 
> been moved (or in a specific cases, are about to be moved) from static 
> methods on Constant to instance methods on LLVMContext.
>
> However, as was recently pointed out on llvm-commits and on IRC, this 
> is no longer strictly necessary.  Because types have contexts, all of 
> the constant subclasses could be friended to LLVMContext, and then put 
> the work of uniquing by accessing the context off of the type.
>
> There are obviously some pros and to both approaches.  Going back to 
> the old-style increases compatibility with 2.5, and breaks up the 
> massive LLVMContext class.  On the downside, it would cause massive 
> thrashing on TOT, because I will have to revert about two weeks worth 
> of commits in widely dispersed parts of the tree, and because a number 
> of clients have already switched to the new TOT API.
>
> Any comments and/or opinions on this decision are welcome.
>
> --Owen
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Nicholas,
> What if I want to have global llvm::Type's, that can be used by many
> LLVMContext's. For example, I'd like to have one LLVMContext per
> function, and  be able to create constants that belong to the context
> but using a global, shared amongst LLVMContext's, llvm::Type.
>
> I know that's not doable right now, but aren't we losing this
> possibility if we move back to the old static functions?
That wasn't going to be possible with the methods-on-LLVMContext  
either.  The Type uniquing tables will be moving onto the context for  
similar reasons to the Constant ones, though we will make an effort to  
preserve the existing APIs.

I'm not sure I understand your goal with having one context per  
function.  In general, each Module can have its own context, but  
functions within the same module need to have the same one, so that  
function types compare correctly, and so that constants in globals  
work properly.  Trying to get around this is likely to cause screwy  
results, as things that should compare as equal won't.

Hope that helps,

--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090728/55b4d747/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2620 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090728/55b4d747/attachment.bin>

On Thursday 23 July 2009 23:14, Chris Lattner wrote:
> Unless there is a good reason not to, I think that sticking to the
> LLVM 2.5-style of APIs makes sense.
Yes, definitely.  The more stability across releases, the better.

                         -Dave