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

C Bergström via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 15 08:09:52 PDT 2016


On Tue, Mar 15, 2016 at 6:44 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Mon, Mar 14, 2016 at 6:51 PM Jason Henline via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>>
>> I think it would be great if StreamExecutor could use liboffload to
>> perform its offloading under the hood. Right now offloading is handled in
>> StreamExecutor using platform plugins, so I think it could be very natural
>> for us to write a plugin which basically forwards to liboffload.
>
>
> I think that having a liboffload plugin would be nice, but I don't think we
> should really base everything on top of this for a few reasons:
>
> 1) I think we already have a nice plugin interface specifically designed to
> support out-of-tree platforms with StreamExecutor, and it wouldn't make a
> lot of sense to force them to re-implement there stuff.
>
> 2) Some platforms may not want or be able to use the liboffload style
> plugin.
>
> 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.

I see the distinction of being "agnostic" and welcoming different
plugins, but at the same time I asked how Google was engaging hw
stakeholders. The feedback from Intel if I heard them correctly - they
would warmly welcome some liboffload integration. (Which would enable
PHI support if I'm not mistaken?)

While I don't think anyone will try to block the integration of this
on whether it does or doesn't have support for liboffload - I think
you may win more friends if it does.

IMHO, until this gets market traction I don't think it's ready for
inclusion. There's lots of really great ideas, but there should be
some threshold of _____________ (importance?) before it's included. (I
apologize I can't word this previous sentence perfectly) /* I really
wish there was some way to have it be an "incubator" before formal
inclusion */
------------
Down the road it raises other questions like is it something google
would want enabled and packaged by default?

Also on a technical level I'd like to see some roadmap which Google
plans and if/how they will get feedback from the industry/users/etc.
This ties into previous comments - is it a "standard" or how will you
develop it - openly, semi-open or entirely behind closed doors.

Without a good testsuite and examples - it doesn't feel like there's a
lot of commitment to it. (I apologize as I may have missed if such a
thing exists)


More information about the llvm-dev mailing list