<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I think your idea is very interesting. However, some of the issues that concern you might not be as bad as you think.</div><br><div><div>On Mar 30, 2009, at 9:19 AM, Milos Puzovic wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">2009/3/30 someguy <span dir="ltr"><<a href="mailto:just.s0m3.guy%2Bllvmdev@gmail.com">just.s0m3.guy+llvmdev@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div dir="ltr">Can you not achieve the same effect without adding intrinsics? Insert function calls to a __spawn and __join pseudo-function instead?</div></blockquote><div>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 <span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">and therefore making much more changes to the existing front-end of your existing language if you want it to support parallel programing.</span></div></div></blockquote><div><br></div><div>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.</div><div><br></div><br><blockquote type="cite"><div class="gmail_quote"><div> 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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><br><blockquote type="cite"><div class="gmail_quote"><div> 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 :)<br></div></div></blockquote><div><br></div><div>If you are planning to use something like pthreads, the compiler will need to add function calls to the code anyway.</div><div><br></div><br><blockquote type="cite"><div class="gmail_quote"><div>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.<br> <br>Thanks,<br>Milos.<br></div></div> _______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></body></html>