Ok, so let's focus on your constructive points.
From: Openmp-dev [mailto:email@example.com] On Behalf
Of C Bergström via Openmp-dev
Sent: Thursday, June 16, 2016 8:06 PM
To: Hal Finkel
Cc: LLVM-OpenMP (firstname.lastname@example.org)
Subject: Re: [Openmp-dev] OpenMP 4 offloading status
>> From: "C Bergström via Openmp-dev" <email@example.com>
>> To: "Samuel Antão" <firstname.lastname@example.org>
>> Cc: "LLVM-OpenMP (email@example.com)"
>> 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
> Given that I doubt that's literally true, let's keep the criticism constructive,
please. Making comments like this only detracts from your more-
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