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

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 1 14:30:20 PDT 2016


----- Original Message -----
> From: "C Bergström" <cbergstrom at pathscale.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "andreybokhanko" <andreybokhanko at gmail.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev"
> <cfe-dev at lists.llvm.org>, "openmp-dev" <openmp-dev at lists.llvm.org>, "Chandler Carruth" <chandlerc at gmail.com>, "Carlo
> Bertolli" <cbertol at us.ibm.com>
> Sent: Wednesday, June 1, 2016 4:25:30 PM
> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support
> libraries
> 
> ignorable tangent -
> 
> compiler-rt conforms to a defacto standard since it models after
> libgcc interface, no? compiler-rt is also dead boring and stable
> (good
> things) (well.. asan keeps them busy, but that doesn't impact the
> interface..)

Sanitizers, Profiling, etc.

> 
> OMP runtime - huh? There's obviously an implementation wrapper around
> pthreads for the compiler to chew on, but the exported/user facing
> portions certainly do or should conform to the OMP standard.
> Everything that is user facing is well defined and the whole process
> from TR to finalization is established...

For a compiler-infrastructure project, user-facing means different things to different people. SE, for example, might sit underneath a parallel STL implementation. OpenMP might too. There are lots of options, and SE's interface itself might not be the primary means via which end users interact with it.

 -Hal

> 
> 
> On Thu, Jun 2, 2016 at 5:07 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> >
> > ________________________________
> >
> > From: "andreybokhanko" <andreybokhanko at gmail.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "C Bergström" <cbergstrom at pathscale.com>, "llvm-dev"
> > <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-dev at lists.llvm.org>,
> > "openmp-dev"
> > <openmp-dev at lists.llvm.org>, "Chandler Carruth"
> > <chandlerc at gmail.com>,
> > "Carlo Bertolli" <cbertol at us.ibm.com>
> > Sent: Wednesday, June 1, 2016 10:43:39 AM
> > Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an
> > LLVM
> > subproject for parallelism runtime and support libraries
> >
> > Hal,
> >
> > 1 июня 2016 г., в 14:22, Hal Finkel <hfinkel at anl.gov> написал(а):
> >
> > I agree that the 'openmp' runtime project logically fits within the
> > purview
> > of a 'parallel' project. We may even want to move it there
> > eventually. We
> > might also want it to remain separate while the project uses its
> > own coding
> > conventions (which are different from LLVM's coding conventions for
> > historical reasons). We're not yet had that conversation, but it is
> > a good
> > one to have.
> >
> >
> > Any reasons why we want to disrupt an established project and its
> > users?
> > Just because we prefer "parallel" as a name for a new project and
> > want to
> > validate this choice by moving an actual parallel runtime there?
> >
> > I have no burning desire to shuffle around repositories for fun ;)
> > -- I was
> > simply validating the point that the 'openmp' project could
> > logically fit
> > within a larger project providing parallel runtimes. We should do
> > this only
> > if there is a compelling reason. I see encouraging interaction
> > between
> > developers working on similar things as a compelling reason. It is
> > not clear
> > that applies in this case.
> >
> >
> > Also, Chris' arguments on SE's lack of  users / standard body make
> > a lot of
> > sense to me. I remember that CilkPlus was rejected for the same
> > reasons. Why
> > SE (PPM, not the library) is different?
> >
> > We have some projects that conform to standard interfaces and some
> > that
> > don't. There's no standard for much of compiler-rt's interface, for
> > example.
> > The OpenMP runtime library itself does not conform to any
> > particular
> > standardized interface (excepting OMP-T). We don't have CilkPlus
> > in-tree in
> > Clang, and we don't have UPC either. We don't have a lot of
> > potential
> > extensions in Clang, although we do certainly have some, and this
> > is not the
> > right thread on which to discuss that issue, for SE or anything
> > else.
> >
> > Thanks again,
> > Hal
> >
> >
> > Yours,
> > Andrey
> >
> >
> >
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory


More information about the llvm-dev mailing list