<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jun 8, 2015 at 7:55 AM Samuel F Antao <<a href="mailto:sfantao@us.ibm.com">sfantao@us.ibm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I probably do not fully understand the programing model behind the Myriad 2 platform, but based on the explanation I seem to detect some overlap with the OpenMP offloading programing model. We have a patch that proposes some changes in the driver to support OpenMP offloading - <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D9888&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=C4r5n8Ct1XzIZB5iAtZKW3W70qL3zmYWb-RT1Li_H5E&s=77TYj2i_l81A8G21ThschXdtcFU1khTK0h11fHopFkI&e=" target="_blank">http://reviews.llvm.org/D9888</a> - however, it does not propose to use anything different from Clang. Could this platform benefit from anything we are proposing in there?</div></div></blockquote><div><br></div><div>Quite possibly. However, we're currently just trying to get Clang to work better with the existing tools and explicitly offloaded code. Leveraging OpenMP offloading (or any other form of automatic offloading) would be a somewhat different effort I suspect.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks,</div><div>Samuel  </div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-05 15:15 GMT-04:00 Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I just wanted to follow up here with more concrete context on what we're working on for folks.<br><br>We'd like to be able to use Clang with the Myriad 2 platform from Movidius[1]. These chips have accelerators (called SHAVEs) that are targeted by a special compiler and other tools in their dev kit (the MDK). We want to use the Clang driver when targeting the platform, with normal Clang and LLVM targeting the CPU and using the custom compiler for code targeting the special SHAVE processors.<div><br></div><div>Hope that helps people understand the use case here.</div><div><br></div><div>-Chandler</div><div><br></div><div>[1]: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.movidius.com_our-2Dtechnology_myriad-2D2-2Dplatform_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=vYtmGebCDsug_Hs1i6g07OAR60cASC_ssw073YrxSj4&s=lPhmQ-d9wtVmDzwWqjUxwW7eehWINU70R451XtcCVF8&e=" target="_blank">http://www.movidius.com/our-technology/myriad-2-platform/</a></div></div><br><div class="gmail_quote"><div><div><div dir="ltr">On Fri, Jun 5, 2015 at 10:03 AM Douglas Katzman <<a href="mailto:dougk@google.com" target="_blank">dougk@google.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi folks,<div><br><div>I put a small change up on Phabricator which has gotten more lines of feedback than lines of source touched, so at the suggestion of the reviewer (Chandler) I'd like to call attention to the limitation this patch starts to address. <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10246&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=isl0i6sDYGuKgTCVwNhPlRv7CkLfyBPym7wDaDauND8&s=gyWrhthaKH3hzoAPgD3k1YIbz5Q_QExs0JHB_ozrjbw&e=" target="_blank">http://reviews.llvm.org/D10246</a></div></div><div><br></div><div>Suppose you want to generate code for some uncommon chip. The hardware manufacturer gives you a C compiler and assembler that are ostensibly black boxes- they might use pieces of llvm, but we don't know / don't care, initially anyway.</div><div><br></div><div>If your workflow entails always running 'clang' as your compiler, what you'd like is that invoking clang with '-target=dinglehopper250x' runs the opaque tools.</div><div>This is either a migration path or a permanent solution depending on whether llvm support will eventually exist.</div><div><br></div><div>For this to work, it's a straightforward matter to add a backend name to llvm that it can't generate code for, have that backend pick a toolchain with custom behavior, and then modify ConstructJob to produce arguments to the foreign tools.</div><div>To avoid users having to know that the vendor-provided compiler has to be invoked with various mystery options, we can put the options into the clang driver, which will add them in when it sees that specific target architecture.</div><div><br></div><div>The problem one encounters immediately is that the clang driver thinks that the clang compiler is always the right tool to compile C. This logic is ingrained in 'types::isAcceptedByClang' and 'Driver::ShouldUseClangCompiler' which return true for the C family.</div><div>My patch makes it possible for the ToolChain itself (the clang object that models the external command-line programs) to make that decision.</div><div><br></div><div>Please let me know if the above is clear and/or whether "there's a better way."</div><div><br></div><div>Doug</div></div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div>