llvm dev - Mar 2016 - [cfe-dev] [Openmp-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries

I did a more thorough read through liboffload and wrote up a more detailed
doc describing how StreamExecutor platforms relate to libomptarget RTL
interfaces. The doc also describes why the lack of support for streams in
libomptarget makes it impossible to implement some of the most important
StreamExecutor platforms in terms of libomptarget (
https://github.com/henline/streamexecutordoc/blob/master/se_and_openmp.rst).
When I was originally optimistic about using liboffload to implement
StreamExecutor platforms, I was not aware of this issue with streams.
Thanks to Carlo Bertolli for bringing this to my attention.

After having looked in detail at the liboffload code, it sounds like the
best thing to do at this point is to keep StreamExecutor and liboffload
separate, but to leave the door open to implement future StreamExecutor
platforms in terms of liboffload. From the recent messages on this subject
from Carlo and Andrey it seems like there is a general consensus on this,
so I would like to move forward with the StreamExecutor project in this
spirit.

On Tue, Mar 15, 2016 at 5:09 PM Jason Henline <jhen at google.com> wrote:
> I created a GitHub repo that contains the documentation I have been
> creating for StreamExecutor. https://github.com/henline/streamexecutordoc
>
> It contains the design docs from the original email in this thread, and it
> contains a new doc I just made that gives a more detailed sketch of the
> StreamExecutor platform plugin interface. This shows which methods must be
> implemented to support a new platform in StreamExecutor, or to provide a
> new implementation for an existing platform (e.g. using liboffload to
> implement the CUDA platform).
>
> I wrote up this doc in response to a lot of good questions I am getting
> about the details of how StreamExecutor might work with the code OpenMP
> already has in place.
>
> Best Regards,
> -Jason
>
> On Tue, Mar 15, 2016 at 12:28 PM Andrey Bokhanko <andreybokhanko at
gmail.com>
> wrote:
>
>> Hola Chandler,
>>
>> On Tue, Mar 15, 2016 at 1:44 PM, Chandler Carruth via Openmp-dev <
>> openmp-dev at lists.llvm.org> wrote:
>>
>>> It seems like if the OpenMP folks want to add a liboffload plugin
to
>>> StreamExecutor, that would be an awesome additional platform, but I
don't
>>> see why we need to force the coupling here.
>>>
>>>
>> Let me give you a reason: while user-facing sides of StreamExecutor and
>> OpenMP are quite different (and each warrants its place under the
sun!),
>> internal SE's offloading interface and liboffload are doing exactly
the
>> same thing. Why we want to duplicate code? As previous replies
>> demonstrated, SE can't serve OpenMP's needs, while liboffload
API seems to
>> be general enough to serve SE well (though this has to be verified, of
>> course -- as I understand, Jason is going to do this).
>>
>> Sure, there is no "must have need" to couple SE and
liboffload, but this
>> sounds like a solid software engineering decision to me. Or, quoting
Jason,
>> who said this much better than me:
>>
>> > Although OpenMP and StreamExecutor support different programming
models,
>> > some of the work they perform under the hood will likely be very
>> similar.
>> > By sharing code and domain expertise, both projects will be
improved and
>> > strengthened as their capabilities are expanded. The
StreamExecutor
>> > community looks forward to much collaboration and discussion with
OpenMP
>> > about the best places and ways to cooperate.
>>
>> Espere veure't demà!
>>
>> Yours,
>> Andrey
>> ====>> Enginyer de Software
>> Intel Compiler Team
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160328/116d5405/attachment.html>

Hi Jason,

This is probably because I'm not aware of the details, but it was claimed in
this thread that liboffload can target Xeon Phi and Nvidia GPUs. Adding a new
library that the compiler has to be aware of has to bring significant benefit.
So it is not clear to me yet why the compiler should target two different
runtime libraries that seems to have large chunk of overlapping functionalities.
On a high-level view, these libraries seems to have the same goals with respect
to what they provide to the compiler.

Can you elaborate?

Thanks,

-- 
Mehdi

> On Mar 28, 2016, at 9:37 AM, Jason Henline via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I did a more thorough read through liboffload and wrote up a more detailed
doc describing how StreamExecutor platforms relate to libomptarget RTL
interfaces. The doc also describes why the lack of support for streams in
libomptarget makes it impossible to implement some of the most important
StreamExecutor platforms in terms of libomptarget
(https://github.com/henline/streamexecutordoc/blob/master/se_and_openmp.rst
<https://github.com/henline/streamexecutordoc/blob/master/se_and_openmp.rst>).
When I was originally optimistic about using liboffload to implement
StreamExecutor platforms, I was not aware of this issue with streams. Thanks to
Carlo Bertolli for bringing this to my attention.
> 
> After having looked in detail at the liboffload code, it sounds like the
best thing to do at this point is to keep StreamExecutor and liboffload
separate, but to leave the door open to implement future StreamExecutor
platforms in terms of liboffload. From the recent messages on this subject from
Carlo and Andrey it seems like there is a general consensus on this, so I would
like to move forward with the StreamExecutor project in this spirit.
> 
> On Tue, Mar 15, 2016 at 5:09 PM Jason Henline <jhen at google.com
<mailto:jhen at google.com>> wrote:
> I created a GitHub repo that contains the documentation I have been
creating for StreamExecutor. https://github.com/henline/streamexecutordoc
<https://github.com/henline/streamexecutordoc>
> 
> It contains the design docs from the original email in this thread, and it
contains a new doc I just made that gives a more detailed sketch of the
StreamExecutor platform plugin interface. This shows which methods must be
implemented to support a new platform in StreamExecutor, or to provide a new
implementation for an existing platform (e.g. using liboffload to implement the
CUDA platform).
> 
> I wrote up this doc in response to a lot of good questions I am getting
about the details of how StreamExecutor might work with the code OpenMP already
has in place.
> 
> Best Regards,
> -Jason
> 
> On Tue, Mar 15, 2016 at 12:28 PM Andrey Bokhanko <andreybokhanko at
gmail.com <mailto:andreybokhanko at gmail.com>> wrote:
> Hola Chandler,
> 
> On Tue, Mar 15, 2016 at 1:44 PM, Chandler Carruth via Openmp-dev
<openmp-dev at lists.llvm.org <mailto:openmp-dev at lists.llvm.org>>
wrote:
> It seems like if the OpenMP folks want to add a liboffload plugin to
StreamExecutor, that would be an awesome additional platform, but I don't
see why we need to force the coupling here.
> 
> 
> Let me give you a reason: while user-facing sides of StreamExecutor and
OpenMP are quite different (and each warrants its place under the sun!),
internal SE's offloading interface and liboffload are doing exactly the same
thing. Why we want to duplicate code? As previous replies demonstrated, SE
can't serve OpenMP's needs, while liboffload API seems to be general
enough to serve SE well (though this has to be verified, of course -- as I
understand, Jason is going to do this).
> 
> Sure, there is no "must have need" to couple SE and liboffload,
but this sounds like a solid software engineering decision to me. Or, quoting
Jason, who said this much better than me:
> 
> > Although OpenMP and StreamExecutor support different programming
models,
> > some of the work they perform under the hood will likely be very
similar.
> > By sharing code and domain expertise, both projects will be improved
and
> > strengthened as their capabilities are expanded. The StreamExecutor
> > community looks forward to much collaboration and discussion with
OpenMP
> > about the best places and ways to cooperate.
> 
> Espere veure't demà!
> 
> Yours,
> Andrey
> ====> Enginyer de Software
> Intel Compiler Team
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160328/c38eaf73/attachment.html>

On Tue, Mar 29, 2016 at 1:12 AM, Mehdi Amini via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Hi Jason,
>
> This is probably because I'm not aware of the details, but it was
claimed in
> this thread that liboffload can target Xeon Phi and Nvidia GPUs. Adding a
> new library that the compiler has to be aware of has to bring significant
> benefit.
> So it is not clear to me yet why the compiler should target two different
> runtime libraries that seems to have large chunk of overlapping
> functionalities.
> On a high-level view, these libraries seems to have the same goals with
> respect to what they provide to the compiler.
>
> Can you elaborate?
(Ignore this please)

To butt in with a peanut gallery comment - I suspect it's because
liboffload is really just providing a bare set of non-portable API
mostly tailored to OpenMP4. Having it support any other programming
model is probably going to take real work on the part of refactoring
"liboffload". (*cough* *cough* good design)

In the end I pessimistically suspect each programming model wanting
inclusion will reinvent the wheel and make the same argument each
time. So we'll end up with lots of libraries doing mostly the same
thing, duplicate code/support.. etc

On Mon, Mar 28, 2016 at 10:12 AM Mehdi Amini <mehdi.amini at apple.com>
wrote:
> Hi Jason,
>
> This is probably because I'm not aware of the details, but it was
claimed
> in this thread that liboffload can target Xeon Phi and Nvidia GPUs. Adding
> a new library that the compiler has to be aware of has to bring significant
> benefit.
> So it is not clear to me yet why the compiler should target two different
> runtime libraries that seems to have large chunk of overlapping
> functionalities.
> On a high-level view, these libraries seems to have the same goals with
> respect to what they provide to the compiler.
>
I think there are at least two issues:

1) Provide a high level C++ stream-based API that integrates cleanly with
compiler-generated kernel dispatch (CUDA or OpenCL, or...)

2) Support the necessary APIs for being a runtime backend for CUDA code.

I think both of these are really important and not really covered at all by
liboffload in its current form.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160328/f19f0d8b/attachment.html>

<div class="socmaildefaultfont" dir="ltr"
style="font-family:Arial;font-size:10.5pt" ><div
dir="ltr" style="font-family:Arial;font-size:10.5pt"
><div dir="ltr" >Jason,</div>
<div dir="ltr" > </div>
<div dir="ltr" >I concur with your decision since OMP and
StreamExecutor fundamentally differ in how dependences between consecutive tasks
are expressed. OMP uses task dependences to express constraint ordering between
tasks that execute on the host and/or on a particular device. Obviously, a
stream is a DAG but with very specific constraints (one linear ordering per
stream), whereas DAG generated by OMP dependences are arbitrary DAGs. This is
not a jugement statement, as in many ways stream are much more friendly to GPUs,
it is just a decision that the OMP and StreamExecutor "language
experts" settled on a different language expressivity/efficiency data
point.</div>
<div dir="ltr" > </div>
<div dir="ltr" >I read your blog on the similarities and
differences with great interest. I may venture to add another overlooked
difference: OMP maps objects with references counts (e.g. first time an object
is mapped, its ref count is zero, and the alloc on device and memory copy will
occur; further nested map will not generate any alloc and/or communication). In
summary, OMP primarily uses a dictionary of mapped variables to manage
allocation and data transfer, whereas StreamExecutor it appears to explicitly
allocate and move data.</div>
<div dir="ltr" style="font-family:Arial;font-size:10.5pt"
><div dir="ltr"
style="font-family:Arial;font-size:10.5pt" ><div
dir="ltr" style="font-family:Arial;font-size:10.5pt"
><div dir="ltr"
style="font-family:Arial;font-size:10.5pt" ><div
dir="ltr" > </div>
<div dir="ltr" >Thanks for your work on this, much
appreciated</div>
<div dir="ltr"
><br>Alexandre<br><br>-----------------------------------------------------------------------------------------------------<br><span
style="color:#0000CD;" >Alexandre Eichenberger, Master Inventor,
Advanced Compiler Technologies</span><br><span
style="color:#0000CD;" >- research</span>: compiler
optimization (OpenMP, multithreading, SIMD)<br><span
style="color:#0000CD;" >- info:</span> alexe@us.ibm.com
http://www.research.ibm.com/people/a/alexe<br><span
style="color:#0000CD;" >- phone</span>: 914-945-1812 (work)
914-312-3618 (cell)</div></div></div></div></div>
<div dir="ltr" > </div>
<div dir="ltr" > </div>
<blockquote data-history-content-modified="1" dir="ltr"
style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px;
direction:ltr; margin-right:0px" >----- Original message
-----<br>From: Jason Henline via Openmp-dev
<openmp-dev@lists.llvm.org><br>Sent by: "Openmp-dev"
<openmp-dev-bounces@lists.llvm.org><br>To: Andrey Bokhanko
<andreybokhanko@gmail.com>, Chandler Carruth
<chandlerc@google.com><br>Cc: llvm-dev
<llvm-dev@lists.llvm.org>, cfe-dev <cfe-dev@lists.llvm.org>,
"openmp-dev@lists.llvm.org"
<openmp-dev@lists.llvm.org><br>Subject: Re: [Openmp-dev] [cfe-dev]
RFC: Proposing an LLVM subproject for parallelism runtime and support
libraries<br>Date: Mon, Mar 28, 2016 12:38 PM<br>
<div dir="ltr" ><div>I did a more thorough read through
liboffload and wrote up a more detailed doc describing how StreamExecutor
platforms relate to libomptarget RTL interfaces. The doc also describes why the
lack of support for streams in libomptarget makes it impossible to implement
some of the most important StreamExecutor platforms in terms of libomptarget
(<a
href="https://github.com/henline/streamexecutordoc/blob/master/se_and_openmp.rst"
target="_blank"
>https://github.com/henline/streamexecutordoc/blob/master/se_and_openmp.rst</a>).
When I was originally optimistic about using liboffload to implement
StreamExecutor platforms, I was not aware of this issue with streams. Thanks to
Carlo Bertolli for bringing this to my attention.</div>
<div> </div>
<div>After having looked in detail at the liboffload code, it sounds like
the best thing to do at this point is to keep StreamExecutor and liboffload
separate, but to leave the door open to implement future StreamExecutor
platforms in terms of liboffload. From the recent messages on this subject from
Carlo and Andrey it seems like there is a general consensus on this, so I would
like to move forward with the StreamExecutor project in this
spirit.</div></div>

<div><div dir="ltr" >On Tue, Mar 15, 2016 at 5:09 PM Jason
Henline <<a href="mailto:jhen@google.com"
target="_blank" >jhen@google.com</a>> wrote:</div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex" ><div dir="ltr" >I created a
GitHub repo that contains the documentation I have been creating for
StreamExecutor. <a
href="https://github.com/henline/streamexecutordoc"
target="_blank"
>https://github.com/henline/streamexecutordoc</a>
<div> </div>
<div>It contains the design docs from the original email in this thread,
and it contains a new doc I just made that gives a more detailed sketch of the
StreamExecutor platform plugin interface. This shows which methods must be
implemented to support a new platform in StreamExecutor, or to provide a new
implementation for an existing platform (e.g. using liboffload to implement the
CUDA platform).</div>
<div> </div>
<div>I wrote up this doc in response to a lot of good questions I am
getting about the details of how StreamExecutor might work with the code OpenMP
already has in place.</div>
<div> </div>
<div>Best Regards,</div>
<div>-Jason</div></div> 

<div><div dir="ltr" >On Tue, Mar 15, 2016 at 12:28 PM
Andrey Bokhanko <<a href="mailto:andreybokhanko@gmail.com"
target="_blank" >andreybokhanko@gmail.com</a>>
wrote:</div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex" ><div dir="ltr" >Hola
Chandler,</div>
<div dir="ltr" ><div> </div>
<div>On Tue, Mar 15, 2016 at 1:44 PM, Chandler Carruth via Openmp-dev
<span dir="ltr" ><<a
href="mailto:openmp-dev@lists.llvm.org" target="_blank"
>openmp-dev@lists.llvm.org</a>></span>
wrote:</div></div>
<div dir="ltr" ><div><div><blockquote
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"
><div dir="ltr" ><div><div dir="ltr"
><span>It seems like if the OpenMP folks want to add a liboffload
plugin to StreamExecutor, that would be an awesome additional platform, but I
don't see why we need to force the coupling here.</span></div>
<div> </div></div></div></blockquote>
<div> </div></div></div></div>
<div dir="ltr" ><div><div><div>Let me give you
a reason: while user-facing sides of StreamExecutor and OpenMP are quite
different (and each warrants its place under the sun!), internal SE's
offloading interface and liboffload are doing exactly the same thing. Why we
want to duplicate code? As previous replies demonstrated, SE can't serve
OpenMP's needs, while liboffload API seems to be general enough to serve SE
well (though this has to be verified, of course -- as I understand, Jason is
going to do this).</div>
<div> </div>
<div>Sure, there is no "must have need" to couple SE and
liboffload, but this sounds like a solid software engineering decision to me.
Or, quoting Jason, who said this much better than
me:</div></div></div></div>
<div dir="ltr" ><div><div><div> </div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap"
>> Although OpenMP and StreamExecutor support different programming
models,</span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap"
>> some of the work they perform under the hood will likely be very
similar.</span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap"
>> By sharing code and domain expertise, both projects will be improved
and</span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap"
>> strengthened as their capabilities are expanded. The
StreamExecutor</span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap"
>> community looks forward to much collaboration and discussion with
OpenMP</span></div>
<div><span style="color:rgb(0,0,0);white-space:pre-wrap"
>> about the best places and ways to cooperate.</span></div>
<div> </div></div></div></div>
<div dir="ltr" ><div><div><div><font
color="#000000" ><span style="white-space:pre-wrap"
>Espere veure't demà!</span></font></div>
<div> </div>
<div><font color="#000000" ><span
style="white-space:pre-wrap"
>Yours,</span></font></div>
<div><font color="#000000" ><span
style="white-space:pre-wrap"
>Andrey</span></font></div>
<div><font color="#000000" ><span
style="white-space:pre-wrap"
>=====</span></font></div>
<div><font color="#000000" ><span
style="white-space:pre-wrap" >Enginyer de
Software</span></font></div>
<div><font color="#000000" ><span
style="white-space:pre-wrap" >Intel Compiler
Team</span></font></div>
<div>
</div></div></div></div></blockquote></div></blockquote></div>
<div><font face="Default Monospace,Courier
New,Courier,monospace" size="2"
>_______________________________________________<br>Openmp-dev mailing
list<br>Openmp-dev@lists.llvm.org<br><a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev"
target="_blank"
>http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev</a></font></div></blockquote>
<div dir="ltr" > </div></div></div><BR>

Hi Jason,

The long discussion made me wondering where this was going, but re-reading you
original email [0], there was an acknowledgment of a potential future merge
between the projects, and I can of make sense of the current picture.
So you can forget about my question below!

[0]: http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html
<http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html>

Best,

--
Mehdi


> On Mar 28, 2016, at 10:12 AM, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi Jason,
> 
> This is probably because I'm not aware of the details, but it was
claimed in this thread that liboffload can target Xeon Phi and Nvidia GPUs.
Adding a new library that the compiler has to be aware of has to bring
significant benefit.
> So it is not clear to me yet why the compiler should target two different
runtime libraries that seems to have large chunk of overlapping functionalities.
> On a high-level view, these libraries seems to have the same goals with
respect to what they provide to the compiler.
> 
> Can you elaborate?
> 
> Thanks,
> 
> -- 
> Mehdi
> 
> 
>> On Mar 28, 2016, at 9:37 AM, Jason Henline via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> I did a more thorough read through liboffload and wrote up a more
detailed doc describing how StreamExecutor platforms relate to libomptarget RTL
interfaces. The doc also describes why the lack of support for streams in
libomptarget makes it impossible to implement some of the most important
StreamExecutor platforms in terms of libomptarget
(https://github.com/henline/streamexecutordoc/blob/master/se_and_openmp.rst
<https://github.com/henline/streamexecutordoc/blob/master/se_and_openmp.rst>).
When I was originally optimistic about using liboffload to implement
StreamExecutor platforms, I was not aware of this issue with streams. Thanks to
Carlo Bertolli for bringing this to my attention.
>> 
>> After having looked in detail at the liboffload code, it sounds like
the best thing to do at this point is to keep StreamExecutor and liboffload
separate, but to leave the door open to implement future StreamExecutor
platforms in terms of liboffload. From the recent messages on this subject from
Carlo and Andrey it seems like there is a general consensus on this, so I would
like to move forward with the StreamExecutor project in this spirit.
>> 
>> On Tue, Mar 15, 2016 at 5:09 PM Jason Henline <jhen at google.com
<mailto:jhen at google.com>> wrote:
>> I created a GitHub repo that contains the documentation I have been
creating for StreamExecutor. https://github.com/henline/streamexecutordoc
<https://github.com/henline/streamexecutordoc>
>> 
>> It contains the design docs from the original email in this thread, and
it contains a new doc I just made that gives a more detailed sketch of the
StreamExecutor platform plugin interface. This shows which methods must be
implemented to support a new platform in StreamExecutor, or to provide a new
implementation for an existing platform (e.g. using liboffload to implement the
CUDA platform).
>> 
>> I wrote up this doc in response to a lot of good questions I am getting
about the details of how StreamExecutor might work with the code OpenMP already
has in place.
>> 
>> Best Regards,
>> -Jason
>> 
>> On Tue, Mar 15, 2016 at 12:28 PM Andrey Bokhanko <andreybokhanko at
gmail.com <mailto:andreybokhanko at gmail.com>> wrote:
>> Hola Chandler,
>> 
>> On Tue, Mar 15, 2016 at 1:44 PM, Chandler Carruth via Openmp-dev
<openmp-dev at lists.llvm.org <mailto:openmp-dev at lists.llvm.org>>
wrote:
>> It seems like if the OpenMP folks want to add a liboffload plugin to
StreamExecutor, that would be an awesome additional platform, but I don't
see why we need to force the coupling here.
>> 
>> 
>> Let me give you a reason: while user-facing sides of StreamExecutor and
OpenMP are quite different (and each warrants its place under the sun!),
internal SE's offloading interface and liboffload are doing exactly the same
thing. Why we want to duplicate code? As previous replies demonstrated, SE
can't serve OpenMP's needs, while liboffload API seems to be general
enough to serve SE well (though this has to be verified, of course -- as I
understand, Jason is going to do this).
>> 
>> Sure, there is no "must have need" to couple SE and
liboffload, but this sounds like a solid software engineering decision to me.
Or, quoting Jason, who said this much better than me:
>> 
>> > Although OpenMP and StreamExecutor support different programming
models,
>> > some of the work they perform under the hood will likely be very
similar.
>> > By sharing code and domain expertise, both projects will be
improved and
>> > strengthened as their capabilities are expanded. The
StreamExecutor
>> > community looks forward to much collaboration and discussion with
OpenMP
>> > about the best places and ways to cooperate.
>> 
>> Espere veure't demà!
>> 
>> Yours,
>> Andrey
>> ====>> Enginyer de Software
>> Intel Compiler Team
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160328/a16abf00/attachment.html>