[LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation

[Vikram S. Adve]

Just to add 2 comments to this discussion:

-- Hans Boehm had an excellent paper in PLDI a few years arguing why  
"threads cannot be a library."  (Google for that phrase.)  This is a  
fundamental problem with compiler optimizations for code that uses  
libraries like pthreads.  This argues in favor of having explicit  
support in the IR.

-- On the other hand, explicitly parallel languages like Java should  
be able to compile to the 'spawn' instruction but finding 'join'  
points is much more difficult.  E.g., there are ways to express  
"ordering" synchronization that could require non-trivial  
interprocedural analysis to extract.

--Vikram
Associate Professor, Computer Science
University of Illinois at Urbana-Champaign
http://llvm.org/~vadve



On Mar 30, 2009, at 10:09 AM, Milos Puzovic wrote:

> Hi Anthony,
>
> 2009/3/30 Anthony Danalis <adanalis at eecs.utk.edu>
> Is the user expected to add the calls to spawn/join or the  
> compiler?  If it's the compiler adding them, then you don't need to  
> change the front-end at all, you can do all that in an optimization  
> pass.  If it's the user adding them, then adding calls to  
> "__spawn()" that the compiler will intercept and change into  
> "pthread_create" or whatever, doesn't require changing the front-end  
> either.
> At the moment I am interested to languages where parallelism is  
> explicit and the way how language developers want to express that  
> parallelism I want to leave entirely to them. I wouldn't like to  
> restrict them with a special construct or keyword and want to leave  
> them as much freedom as possible. Also, I would like, which I think  
> is very important, to try to separate sequential calls and parallel  
> calls.
>
> I don't see why looking at function calls is hard.  If the compiler  
> knows which functions to look for, has exact knowledge of the  
> semantics/side-effects/dependencies of the calls and assumes that  
> there can never be a different function that happened to have the  
> same name, then analyzing and manipulating function calls is the  
> same as manipulating intrinsics.
> I agree it is not hard but it can be tiresome because as you have  
> explained there is a lot of knowledge that compiler needs to acquire  
> and also a lot of assumptions that it needs to make (and some of  
> them might not be guaranteed if you get, for examples, third-party  
> implementation). By introducing this new level of abstraction my  
> hope is to get much cleaner code base.
>
> Thanks,
> Milos.
> <ATT00001.txt>