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

On Jul 24, 2009, at 9:30 AM, Duncan Sands wrote:
>> 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.
>
> Why is that?  If it is read-only then it should be possible to share
> it between all threads.
Type's aren't readonly, see all the mutable fields in them.  While we  
might be able to get away with a special case for these, I'd rather  
have a clean model where no IR is shared across contexts.

-Chris

Hi,

On Fri, Jul 24, 2009 at 7:03 PM, Chris Lattner <clattner at apple.com>
wrote:
>
> On Jul 24, 2009, at 9:30 AM, Duncan Sands wrote:
>
> >> 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.
> >
> > Why is that?  If it is read-only then it should be possible to share
> > it between all threads.
>
> Type's aren't readonly, see all the mutable fields in them.  While
we
> might be able to get away with a special case for these, I'd rather
> have a clean model where no IR is shared across contexts.
>
I'm sorry if I am being dense so please bear with me.

Assuming that I have a threaded JIT server which has an llvmContext object
on the stack of every JITting thread in the server.

When using the 2.5. API like:

 C = llvm::ConstantInt::get(llvm::Type::Int32Ty, 0);

I need to assume that there exists some global llvmContext object which
holds
the predefined llvm types.

Does this entail that in my threaded server I need to create new types for
llvm::Type::Int32Ty and the like,  which are associated with the
llvm::Context on the stack?
Or will things work correctly when mixing values created using the global
context and other stuff created using the context object on the stack of
threads?

I guess that I am trying to say that it seems to me that the 2.5 API is more
prone to synchronization issues than the interim 2.6 version of the API.
The reason for this assumtion is that it seemed clear which context
object governed the lifetime of all llvm related objects.

So why not support the newer interim 2.6 API as well?

Anybody willing to spell out what the rules will be for using
LLVM for multi-threaded JITting?

Thanks.

Kind regards,
Maurice

> -Chris
> _______________________________________________
> 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/20090725/2d5c92a1/attachment.html>

On Jul 25, 2009, at 5:44 AM, Maurice Gittens wrote:
> Assuming that I have a threaded JIT server which has an llvmContext  
> object
> on the stack of every JITting thread in the server.
>
> When using the 2.5. API like:
> C = llvm::ConstantInt::get(llvm::Type::Int32Ty, 0);
>
> I need to assume that there exists some global llvmContext object  
> which holds
> the predefined llvm types.
>
> Does this entail that in my threaded server I need to create new  
> types for
> llvm::Type::Int32Ty and the like,  which are associated with the  
> llvm::Context on the stack?
Yes, you'll have to write something like:

C = llvm::ConstantInt::get(llvm::Type::getInt32Ty(Context), 0);

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090725/c627032e/attachment.html>