[Openmp-dev] OpenMP 4 offloading status

Hahnfeld, Jonas via Openmp-dev openmp-dev at lists.llvm.org
Thu Jun 16 23:34:53 PDT 2016


Ok, so let's focus on your constructive points.

> -----Original Message-----
> From: Openmp-dev [mailto:openmp-dev-bounces at lists.llvm.org] On Behalf
> Of C Bergström via Openmp-dev
> Sent: Thursday, June 16, 2016 8:06 PM
> To: Hal Finkel
> Cc: LLVM-OpenMP (openmp-dev at lists.llvm.org)
> Subject: Re: [Openmp-dev] OpenMP 4 offloading status
> 
> On Fri, Jun 17, 2016 at 1:58 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> > ----- Original Message -----
> >> From: "C Bergström via Openmp-dev" <openmp-dev at lists.llvm.org>
> >> To: "Samuel Antão" <samuelfantao at gmail.com>
> >> Cc: "LLVM-OpenMP (openmp-dev at lists.llvm.org)"
> >> <openmp-dev at lists.llvm.org>
> >> Sent: Thursday, June 16, 2016 12:55:01 PM
> >> Subject: Re: [Openmp-dev] OpenMP 4 offloading status
> >>
> >> So it's not lost or forgotten -
> >>
> >> If the libomptarget is the same thing I'm thinking it is, then it
> >> certainly hasn't had all my comments and feedback addressed.
> >>
> >> 1) The design is not friendly to adding more targets

Full disagree: Add a new RTL and implement the methods described in the interface between libomptarget and its RTLs - simple as that.

> >> 2) If that offloading is meant to be available to another programming
> >> model, it should be abstracted to provide a bit more clean
> >> abstraction instead of just zero layer over the OMP API.

Well, it wasn't meant to if I got this correctly.  That's why I think the current level of abstraction is just right.
Also, they didn't start coding without a plan but first put together a well-thought design document. That was a joint effort by multiple companies involved in the OpenMP standard and its implementation.

Coming back to your wish of abstraction: The interface of the RTLs for example consists of the following methods: __tgt_rtl_data_alloc and __tgt_rtl_data_retrieve
Please tell me
1) how this is "just zero layer over the OMP API" and
2) what your concrete and detailed proposal would be.
I have read your mails about "3 layer abstraction" but they have all been focusing on a very high-level view without a concrete design that someone could evaluate or even think of.

> >>
> >> Lastly and it may be just my opinion, but the way that it's actually
> >> coded looks like some 1st year C programmer just got his license to
> >> code.
> >
> > Given that I doubt that's literally true, let's keep the criticism constructive,
> please. Making comments like this only detracts from your more-
> constructive points.

Completely agree with Hal here: Getting personal is surely not the right way to discuss on technical matters.
(I've already worked on the code and looked into implementing OMPT which worked quite good. Which means that the design can't be complete non-sense...)
 
> 
> So for the record all my comments seem pragmatically ignored. #meh

All right, I've commented on the technical topics above.

> 
> I gave specific comments on that patch for a handful of the nits.
> Regardless of my tone - I'd love to see if it passes clang/llvm coding
> standards, clang-tidy or lint..

Ehm no, that's just not how it works in open-source communities: Be respectful to the others involved in a discussion.
(just another random note: you didn't even say sorry and don't seem to change your behavior...)

As for what you'd love to see: Just look into it - that's the power of open source ;-)

Cheers,
Jonas

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


More information about the Openmp-dev mailing list