search for: bertolli

...uot; <hfinkel at anl.gov> >> Cc: "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>, >> "Andrey Bokhanko" <andreybokhanko at gmail.com> >> Sent: Wednesday, June 1, 2016 6:46:57 AM >> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support >> libr...

...uot; <hfinkel at anl.gov> >> Cc: "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>, >> "Andrey Bokhanko" <andreybokhanko at gmail.com> >> Sent: Wednesday, June 1, 2016 9:42:34 AM >> Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support >> libr...

...l" <hfinkel at anl.gov> > Cc: "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>, "Andrey Bokhanko" <andreybokhanko at gmail.com> > Sent: Wednesday, June 1, 2016 12:19:19 AM > Subject: Re: [Openmp-dev] [llvm-dev] [cfe-dev] RFC: Proposing an LLVM > subproject for parallelism runtime and support libraries > >...

...ct me if I have misunderstood). My analysis from looking through the code was that libomptarget had some similarities with the platform support in SE, so I just wanted to consider how those two libraries compared. I didn't do a comparison with liboffload. On Mon, Mar 28, 2016 at 11:11 AM Carlo Bertolli <cbertol at us.ibm.com> wrote: > Hi > > Reading through the comments: both Chris and Chandler referenced to > liboffload, while I thought the subject of conversation was libomptarget > and SE. > I am being picky about names because liboffload is a library available as >...

...stood). My analysis from looking through the code was that > libomptarget had some similarities with the platform support in SE, so I > just wanted to consider how those two libraries compared. I didn't do a > comparison with liboffload. > > On Mon, Mar 28, 2016 at 11:11 AM Carlo Bertolli <cbertol at us.ibm.com> > wrote: > >> Hi >> >> Reading through the comments: both Chris and Chandler referenced to >> liboffload, while I thought the subject of conversation was libomptarget >> and SE. >> I am being picky about names because liboffloa...

...n-accelerator-based parallel programming runtimes can also potentially have a place here. Thanks again, Hal ----- Original Message ----- > From: "via Openmp-dev" <openmp-dev at lists.llvm.org> > To: "Chandler Carruth" <chandlerc at gmail.com>, "Carlo Bertolli" > <cbertol at us.ibm.com>, "Andrey Bokhanko" <andreybokhanko 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: Wednesday, May 11, 2016 3:5...

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

...from looking through the code was that >> libomptarget had some similarities with the platform support in SE, so I >> just wanted to consider how those two libraries compared. I didn't do a >> comparison with liboffload. >> >> On Mon, Mar 28, 2016 at 11:11 AM Carlo Bertolli <cbertol at us.ibm.com> >> wrote: >> >>> Hi >>> >>> Reading through the comments: both Chris and Chandler referenced to >>> liboffload, while I thought the subject of conversation was libomptarget >>> and SE. >>> I am being pic...

...the code was that >>> libomptarget had some similarities with the platform support in SE, so I >>> just wanted to consider how those two libraries compared. I didn't do a >>> comparison with liboffload. >>> >>> On Mon, Mar 28, 2016 at 11:11 AM Carlo Bertolli <cbertol at us.ibm.com> >>> wrote: >>> >>>> Hi >>>> >>>> Reading through the comments: both Chris and Chandler referenced to >>>> liboffload, while I thought the subject of conversation was libomptarget >>>> and SE....

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

The thread has lost focus and cherry picking replies.. To restate things since maybe you missed my points ---- 1) SE is a programming model and needs a home of it's own. Having a programming model with it's headers and all other stuff glued into a runtime project which intends to be universal and PM agnostic doesn't make sense. 1.1) The more I look, the most it seems SE is just a

...gt;>>> libomptarget had some similarities with the platform support in SE, so I >>>> just wanted to consider how those two libraries compared. I didn't do a >>>> comparison with liboffload. >>>> >>>> On Mon, Mar 28, 2016 at 11:11 AM Carlo Bertolli <cbertol at us.ibm.com> >>>> wrote: >>>> >>>>> Hi >>>>> >>>>> Reading through the comments: both Chris and Chandler referenced to >>>>> liboffload, while I thought the subject of conversation was libomptarget...

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

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

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

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

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

...nterface for Directive (or Pragmas) Representation. Specification Draft v0.9, Intel Corporation, 2016. Acknowledgements ================ We would like to thank Chandler Carruth (Google), Johannes Doerfert (Saarland Univ.), Yaoqing Gao (HuaWei), Michael Wong (Codeplay), Ettore Tiotto, Carlo Bertolli, Bardia Mahjour (IBM), and all other LLVM-HPC IR Extensions WG members for their constructive feedback on the LLVM framework and IR extension proposal. Proposed Implementation ======================= Two sets of patches of supporting these experimental intrinsics and demonstrate the usage are...

...g Interface for Directive (or Pragmas) Representation. Specification Draft v0.9, Intel Corporation, 2016. Acknowledgements ================ We would like to thank Chandler Carruth (Google), Johannes Doerfert (Saarland Univ.), Yaoqing Gao (HuaWei), Michael Wong (Codeplay), Ettore Tiotto, Carlo Bertolli, Bardia Mahjour (IBM), and all other LLVM-HPC IR Extensions WG members for their constructive feedback on the LLVM framework and IR extension proposal. Proposed Implementation ======================= Two sets of patches of supporting these experimental intrinsics and demonstrate the usage are rea...