Milos Puzovic
2009-Mar-30 12:18 UTC
[LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation
Hi Nicolas, 2009/3/30 Nicolas Geoffray <nicolas.geoffray at lip6.fr>> Can you be more verbose on this? Are you planning to implement some JVM > or .Net extension for supporting your new intrinsics? Or are you just > looking for a runtime with a GC?At the moment I am not looking to add any new extensions to JVM or .NET. I would need a runtime with a GC to demonstrate and test building execution schedules using the randomized work-stealing algorithm. I thought that I could factor out some code from VMKit that would help me to get there? Otherwise I would look at working with LLVM interpreter to support multi- and many-core execution with new intrinsic. Once I am happy with the performance I will look into adding extensions to JVM and .NET. Why do you need to hack on a processor backend for such purpose? Aren't> your OS primitives sufficient?Yes they are, but I also want to exploit any specific instructions from the multi-thread processors for creating and distributing threads. For examples, XCore ISA has an instruction TSTART to start and a group of instructions starting with TINIT for initialising different aspects of thread states. It would then be interesting to compare how would that generated code handle load balancing compared to work-stealing algorithm and if they can work together. Milos. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090330/11ad7f7d/attachment.html>
someguy
2009-Mar-30 12:37 UTC
[LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation
Can you not achieve the same effect without adding intrinsics? Insert function calls to a __spawn and __join pseudo-function instead? 2009/3/30 Milos Puzovic <milos.puzovic at gmail.com>> Hi Nicolas, > > 2009/3/30 Nicolas Geoffray <nicolas.geoffray at lip6.fr> > >> Can you be more verbose on this? Are you planning to implement some JVM >> or .Net extension for supporting your new intrinsics? Or are you just >> looking for a runtime with a GC? > > At the moment I am not looking to add any new extensions to JVM or .NET. I > would need a runtime with a GC to demonstrate and test building execution > schedules using the randomized work-stealing algorithm. I thought that I > could factor out some code from VMKit that would help me to get there? > Otherwise I would look at working with LLVM interpreter to support multi- > and many-core execution with new intrinsic. Once I am happy with the > performance I will look into adding extensions to JVM and .NET. > > Why do you need to hack on a processor backend for such purpose? Aren't >> your OS primitives sufficient? > > Yes they are, but I also want to exploit any specific instructions from the > multi-thread processors for creating and distributing threads. For examples, > XCore ISA has an instruction TSTART to start and a group of instructions > starting with TINIT for initialising different aspects of thread states. It > would then be interesting to compare how would that generated code handle > load balancing compared to work-stealing algorithm and if they can work > together. > > 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/f59ac157/attachment.html>
Milos Puzovic
2009-Mar-30 13:19 UTC
[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>
Reasonably Related Threads
- [LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation
- [LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation
- [LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation
- [LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation
- [LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation