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

Mon Apr 25 11:17:13 PDT 2016

+1 to everything Hal said. =D

On Mon, Apr 25, 2016 at 2:14 PM Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "C Bergström via Openmp-dev" <openmp-dev at lists.llvm.org>
> > To: "Chandler Carruth" <chandlerc at gmail.com>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" <
> cfe-dev at lists.llvm.org>, openmp-dev at lists.llvm.org
> > Sent: Monday, April 25, 2016 12:51:51 PM
> > Subject: Re: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Proposing an LLVM
> subproject for parallelism runtime and support
> > libraries
> >
> > Speaking from 1st hand experience -
> >
> > The off-the-cuff high level benefits
> > 1) Better interopt of different programming models - For example what
> > if someone wants to mix SE+OMP(4). Having the same runtime on the
> > backend should make this a lot easier. (Maybe this particular example
> > may never happen, but I hope you get what I'm talking about)
> > 2) Less duplication of effort for common things.
> > 3) Easier time for new programming models
> >
> > By ignoring the current technical issues it's just playing
> > kick-the-can for someone less intimate with SE or OMP.
> >
> > I hate to pushback on SE for this general requirement, but it seems
> > like the right time to do it. If not now - At which point does it
> > make
> > sense?
> > -------------
> > My real honest motivation here is for Google and Intel to join
> > together on this. I believe SE will be much better long term if major
> > stakeholders are aligned.
>
> This is also my long-term desire, and having spoken offline with folks on
> both sides, I think that everyone shares the desire to merge and
> deduplicate where that makes technical sense. We'd all like LLVM's runtime
> picture to truly be an infrastructure, not a patchwork of semi-related
> overlapping things.
>
> However, at this point we have two separate projects representing
> significant independent planning and developer effort, user communities for
> both, and a desire to have both in LLVM. It seems logical that there may be
> reuse to be exploited between the two, but frankly, I don't even thing we
> know exactly what the layering would be. What we need at this point are
> concrete proposals, and patches, to merge functionality. Having these kinds
> of discussions in the abstract is difficult, the code is too large, and its
> design constraints are too complicated, for that to be productive. This
> process could occur out-of-tree, but that's suboptimal. We want the full
> engagement and relative transparency of the LLVM community, and our
> community infrastructure, to facilitate this process. Trying to get these
> issues worked out behind the scenes is unlikely to be successful, and while
> I agree that the community has pre-commit leverage, the most effective way
> to use that leverage is to make it clear to the parties involved that the
> community expects cross-pollination to happen: by code integration, or just
> by intellectual contribution.
>
> Let's get both things committed. Committing them does not freeze the API,
> or otherwise commit us to support for the current implementations. Once
> that's done, we'll be in a much stronger, and better informed, position to
> discuss further refactoring.
>
> Thanks again,
> Hal
>
> >
> > How many dsisjoint and fragmented programming models do "we" really
> > need.. (I don't think SE falls into this category, but if we have a
> > PHI and Intel backend.. why can't it be used)
> >
> >
> >
> > On Tue, Apr 26, 2016 at 1:38 AM, Chandler Carruth
> > <chandlerc at gmail.com> wrote:
> > > On Mon, Apr 25, 2016 at 12:14 PM C Bergström
> > > <cbergstrom at pathscale.com>
> > > wrote:
> > >>
> > >> I can't comment on all the things not directly used by llvm
> > >> community,
> > >> but I feel pretty strongly that
> > >> 1) An independent project like liboffload should exist ; which
> > >> 2) Projects like SE and OpenMP should both be using it ; and
> > >> further
> > >> 3) SE shouldn't just do their own thing because they haven't
> > >> figured
> > >> out how to make it work with other projects that already have some
> > >> overlapping behaviour
> > >> ---------
> > >> If my points above are invalid - can someone clarify that SE and
> > >> the
> > >> "stuff" in OpenMP-llvm doesn't actually overlap in functionality.
> > >
> > >
> > > It isn't that any of these points are invalid, it's just that I
> > > don't think
> > > we know how or if these projects have a useful overlap to extract
> > > and keep
> > > separate. That was the whole point of my email suggesting that we
> > > shouldn't
> > > try to force some hypothetical refactoring that we don't even know
> > > will work
> > > to happen. Several serious technical challenges have been raised
> > > with doing
> > > this refactoring, so its not just avoiding it for the sake of
> > > avoiding it.
> > >
> > > Even if/when these issues are sorted out and it is feasible to
> > > refactor
> > > things to have a common layer, it still isn't clear whether the
> > > overlap is
> > > actually that useful. I think we're over analyzing and designing
> > > this when
> > > we don't even have the code in place to see if there is an
> > > interesting
> > > problem to solve here.
> > _______________________________________________
> > Openmp-dev mailing list
> > Openmp-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160425/db910118/attachment.html>