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

2009/3/30 someguy
<just.s0m3.guy+llvmdev at gmail.com<just.s0m3.guy%2Bllvmdev at
gmail.com>
>
> Can you not achieve the same effect without adding intrinsics? Insert
> function calls to a __spawn and __join pseudo-function instead?
>
It would make LLVM code generation more difficult because instead of
building a new instruction (in this case intrinsic) you will be building
complex function calls and therefore making much more changes to the
existing front-end of your existing language if you want it to support
parallel programing. Analysis of generated LLVM code will become more
difficult because now instead of simply looking at the instructions you will
also need to look at the function calls and see if they are calling any
pseudo-functions which might require changes to the LLVM API as well.
Finally, the same goes when writting a back-end for the processor of your
choice -- you would really like to just add new code for building threads
not to modify the existing one for function calls. In summary, adding
intrinsics gives you a structure and nice code :)

Ideally, I would really like to see these intrinsic as instructions. Because
adding new instructions to LLVM language requires changing all of the
transformation of LLVM and I really want to have working version of code and
useful results by the end of GSoC I have decided to go this way. Once it (if
:) is demonstrated that this extension does aid multi-core code generation
and LLVM community is happy with it I would be happy to add them as
instructions.

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

The reason for my suggestion is that adding intrinsics is also considered to
be a breaking change.
This is the third question/suggestion in the last week or so where the
intrinsics/pseudo-function idea has been raised. Perhaps what llvm really
needs is a 'generic' pseudo-intrinsic of some kind?

2009/3/30 Milos Puzovic <milos.puzovic at gmail.com>
> 2009/3/30 someguy <just.s0m3.guy+llvmdev at
gmail.com<just.s0m3.guy%2Bllvmdev at gmail.com>
> >
>
>> Can you not achieve the same effect without adding intrinsics? Insert
>> function calls to a __spawn and __join pseudo-function instead?
>>
> It would make LLVM code generation more difficult because instead of
> building a new instruction (in this case intrinsic) you will be building
> complex function calls and therefore making much more changes to the
> existing front-end of your existing language if you want it to support
> parallel programing. Analysis of generated LLVM code will become more
> difficult because now instead of simply looking at the instructions you
will
> also need to look at the function calls and see if they are calling any
> pseudo-functions which might require changes to the LLVM API as well.
> Finally, the same goes when writting a back-end for the processor of your
> choice -- you would really like to just add new code for building threads
> not to modify the existing one for function calls. In summary, adding
> intrinsics gives you a structure and nice code :)
>
> Ideally, I would really like to see these intrinsic as instructions.
> Because adding new instructions to LLVM language requires changing all of
> the transformation of LLVM and I really want to have working version of
code
> and useful results by the end of GSoC I have decided to go this way. Once
it
> (if :) is demonstrated that this extension does aid multi-core code
> generation and LLVM community is happy with it I would be happy to add them
> as instructions.
>
> Thanks,
> Milos.
>
> _______________________________________________
> 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/20090330/20eb3b9f/attachment.html>

I think your idea is very interesting.  However, some of the issues  
that concern you might not be as bad as you think.

On Mar 30, 2009, at 9:19 AM, Milos Puzovic wrote:
> 2009/3/30 someguy <just.s0m3.guy+llvmdev at gmail.com>
> Can you not achieve the same effect without adding intrinsics?  
> Insert function calls to a __spawn and __join pseudo-function instead?
> It would make LLVM code generation more difficult because instead of  
> building a new instruction (in this case intrinsic) you will be  
> building complex function calls and therefore making much more  
> changes to the existing front-end of your existing language if you  
> want it to support parallel programing.
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.

> Analysis of generated LLVM code will become more difficult because  
> now instead of simply looking at the instructions you will also need  
> to look at the function calls and see if they are calling any pseudo- 
> functions which might require changes to the LLVM API as well.
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.

> Finally, the same goes when writting a back-end for the processor of  
> your choice -- you would really like to just add new code for  
> building threads not to modify the existing one for function calls.  
> In summary, adding intrinsics gives you a structure and nice code :)
If you are planning to use something like pthreads, the compiler will  
need to add function calls to the code anyway.

> Ideally, I would really like to see these intrinsic as instructions.  
> Because adding new instructions to LLVM language requires changing  
> all of the transformation of LLVM and I really want to have working  
> version of code and useful results by the end of GSoC I have decided  
> to go this way. Once it (if :) is demonstrated that this extension  
> does aid multi-core code generation and LLVM community is happy with  
> it I would be happy to add them as instructions.
>
> Thanks,
> Milos.
> _______________________________________________
> 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/20090330/6233660b/attachment.html>

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>

someguy wrote:
> The reason for my suggestion is that adding intrinsics is also 
> considered to be a breaking change.
> 
> This is the third question/suggestion in the last week or so where the 
> intrinsics/pseudo-function idea has been raised. Perhaps what llvm 
> really needs is a 'generic' pseudo-intrinsic of some kind?
I think part of the reason this happens is because the docs on extending 
LLVM suggest intrinsics as the first approach. It might make sense to 
clarify that intrinsics are only recommended where special code 
generation is required, and suggest just using a library interface for 
anything that can be removed before code generation through IR->IR lowering.

Luke
> 
> 2009/3/30 Milos Puzovic <milos.puzovic at gmail.com 
> <mailto:milos.puzovic at gmail.com>>
> 
>     2009/3/30 someguy <just.s0m3.guy+llvmdev at gmail.com
>     <mailto:just.s0m3.guy%2Bllvmdev at gmail.com>>
> 
>         Can you not achieve the same effect without adding intrinsics?
>         Insert function calls to a __spawn and __join pseudo-function
>         instead?
> 
>     It would make LLVM code generation more difficult because instead of
>     building a new instruction (in this case intrinsic) you will be
>     building complex function calls and therefore making much more
>     changes to the existing front-end of your existing language if you
>     want it to support parallel programing. Analysis of generated LLVM
>     code will become more difficult because now instead of simply
>     looking at the instructions you will also need to look at the
>     function calls and see if they are calling any pseudo-functions
>     which might require changes to the LLVM API as well. Finally, the
>     same goes when writting a back-end for the processor of your choice
>     -- you would really like to just add new code for building threads
>     not to modify the existing one for function calls. In summary,
>     adding intrinsics gives you a structure and nice code :)
> 
>     Ideally, I would really like to see these intrinsic as instructions.
>     Because adding new instructions to LLVM language requires changing
>     all of the transformation of LLVM and I really want to have working
>     version of code and useful results by the end of GSoC I have decided
>     to go this way. Once it (if :) is demonstrated that this extension
>     does aid multi-core code generation and LLVM community is happy with
>     it I would be happy to add them as instructions.
> 
>     Thanks,
>     Milos.
> 
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto: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