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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090330/d7ed48de/attachment.html>

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>

2009/3/30 Vikram S. Adve <vadve at cs.uiuc.edu>

[snip]

> -- 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.
>
One paradigm that I had in mind when proposing join intrinsic was join
calculus where join points are defined explicitly thus simplifying their
discovery. There has been some work to extend Java with it (Hardware Join
Java) and also there are extensions to C#, VB and OCaml while the language
Comega was designed around join calculus. Compared to these languages I
guess Java would be explicit in spawning but implicit in joining :)

Milos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090330/ef9f9b1b/attachment.html>