Displaying 7 results from an estimated 7 matches for "__spawn".
2009 Mar 30
4
[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...
2009 Mar 30
0
[LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation
...owever, 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...
2009 Mar 30
0
[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...
2009 Mar 30
2
[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
2009 Mar 30
0
[LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation
...ome 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 y...
2009 Mar 30
2
[LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation
...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 parall...
2009 Mar 30
0
[LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation
...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...