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

[Milos Puzovic]

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>