llvm dev - Apr 2016 - [Openmp-dev] [cfe-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.

How many disjoint 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.

----- 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

+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>

Hi

Just to clarify where is what to everybody, libomptarget is published as
three incremental patches, here:

http://reviews.llvm.org/D14031
http://reviews.llvm.org/D14253
http://reviews.llvm.org/D14254

This is related to an extension to the current openmp project. I am very
happy to discuss about having this as a separate project.
Right now libomptarget (design+implementation) is very specific to OpenMP,
meaning that its interfaces have been crafted by looking at the OpenMP
specifications. This does not mean that it cannot be improved/generalized
for wider use, but this should start from its design document (can be found
here: https://github.com/clang-omp/OffloadingDesign).

Thanks

-- Carlo




From:	Hal Finkel via Openmp-dev <openmp-dev at lists.llvm.org>
To:	C Bergström <cbergstrom at pathscale.com>
Cc:	llvm-dev <llvm-dev at lists.llvm.org>, cfe-dev
            <cfe-dev at lists.llvm.org>, openmp-dev at lists.llvm.org
Date:	04/25/2016 02:14 PM
Subject:	Re: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Proposing an LLVM
            subproject for parallelism runtime and support libraries
Sent by:	"Openmp-dev" <openmp-dev-bounces at lists.llvm.org>



----- 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
_______________________________________________
Openmp-dev mailing list
Openmp-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160425/40862c72/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160425/40862c72/attachment-0001.gif>

On 25 April 2016 at 19:14, Hal Finkel via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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.
+1.

I can't see anything wrong with this...

--renato

Hi all,

 

I’m also in favor of getting this committed and afterwards thinking about
deduplication because of all the reasons mentioned below.

I’ve provided some feedback on the patches below some time ago, but I’m
mainly fine with the general approach.

 

Cheers,

Jonas

 

From: Openmp-dev [mailto:openmp-dev-bounces at lists.llvm.org] On Behalf Of
Carlo Bertolli via Openmp-dev
Sent: Monday, April 25, 2016 8:26 PM
To: Hal Finkel
Cc: llvm-dev; cfe-dev; openmp-dev at lists.llvm.org
Subject: Re: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Proposing an LLVM
subproject for parallelism runtime and support libraries

 

Hi

Just to clarify where is what to everybody, libomptarget is published as
three incremental patches, here:

http://reviews.llvm.org/D14031
http://reviews.llvm.org/D14253
http://reviews.llvm.org/D14254

This is related to an extension to the current openmp project. I am very
happy to discuss about having this as a separate project.
Right now libomptarget (design+implementation) is very specific to OpenMP,
meaning that its interfaces have been crafted by looking at the OpenMP
specifications. This does not mean that it cannot be improved/generalized
for wider use, but this should start from its design document (can be found
here: https://github.com/clang-omp/OffloadingDesign).

Thanks

-- Carlo


Inactive hide details for Hal Finkel via Openmp-dev ---04/25/2016 02:14:38
PM-------- Original Message ----- > From: "C BergstrHal Finkel via
Openmp-dev ---04/25/2016 02:14:38 PM-------- Original Message ----- > From:
"C Bergström via Openmp-dev" <openmp-dev at lists.llvm.org>

From: Hal Finkel via Openmp-dev <openmp-dev at lists.llvm.org>
To: C Bergström <cbergstrom at pathscale.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>, cfe-dev <cfe-dev at
lists.llvm.org>,
openmp-dev at lists.llvm.org
Date: 04/25/2016 02:14 PM
Subject: Re: [Openmp-dev] [cfe-dev] [llvm-dev] RFC: Proposing an LLVM
subproject for parallelism runtime and support libraries
Sent by: "Openmp-dev" <openmp-dev-bounces at lists.llvm.org>

  _____  




----- 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
_______________________________________________
Openmp-dev mailing list
Openmp-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160426/8e11e170/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160426/8e11e170/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5868 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160426/8e11e170/attachment.bin>