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

someguy just.s0m3.guy+llvmdev at gmail.com
Mon Mar 30 05:37:20 PDT 2009


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>


More information about the llvm-dev mailing list