[cfe-commits] Fw: Re: [PATCH] First OpenMP patch

Chandler Carruth chandlerc at gmail.com
Tue Dec 18 10:18:44 PST 2012


On Tue, Dec 18, 2012 at 3:31 AM, Andrey Bokhanko
<andreybokhanko at gmail.com>wrote:

> Chandler,
>
> > Sorry that this got lost Hal, but I have said on another thread about
> this
> > patch (but with a different author) that I don't really think we should
> add
> > documentation and the beginnings of support for -fopen-mp without first
> > having a clear discussion and document describing the expected design of
> > OpenMP support in Clang.
>
> While personally I do support this "design everything before writing a
> line of code" approach, I'm surprised (and, to be frank, frustrated)
> to see this raised only now, after a whole month of code review and a
> lot of effort already put both by patch developers (Mahesha and
> Alexey) and reviewers (Dmitri and Hal).
>

I think you misunderstood my suggestion a bit (see below), but I'm still
sorry about your feelings here, and I don't think any of this effort was
wasted. I think many of these things can carry on in parallel, I'm just
trying to make sure we don't forget about some elements in pushing through
patches. Eventually we'll need to have the design in place in order to
review patches, and I don't want to discover that late...


> Either way, there were a lot of OpenMP-related discussions in last
> several months. It seems that while everyone considers OpenMP support
> to be desirable for LLVM, opinions on how to handle it in the compiler
> back-end differs.
>
> That's why back in October 9th Mahesha (original author of the patch)
> started a discussion on support in Clang FE only
> (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/024842.html).
>
> He got the following suggestion from Eli
> (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-October/024843.html):
>
> > If you have patches that implement useful functionality; please submit
> > sooner rather than later.  Doing a bunch of work in a private branch
> > will mean more work for you in the long run because you won't get any
> > feedback.
>
> While this definitely differs from "design everything before writing a
> line of code" approach, it seemed to be a reasonable suggestion. It
> still is.
>

Ok.... I think maybe my suggestion came off wrong. I'm definitely not
looking for a complete and finished design. I'd be quite happy with
something very rough, informal, and not fleshed out. I think Eli and my
suggestions are compatible, and if they seem otherwise, we probably are
still misunderstanding each other.

I'm mostly interested in making sure at the high level we're all on the
same page about how the support gets added and fits into the compiler. That
way, when we get to the more interesting patches to review, we'll be
reviewing it from the same end-goal.

I had imagined one of the standard "RFC" emails that is about 4 paragraphs
long, plus maybe a rough list of steps planned in the development.

I also hadn't imagined any hard sequencing between code patches and this
discussion, just that I thought it would be useful to reviewers to have
that discussion on going (and in their heads) when reviewing patches.


>
> > Essentially, I think this patch is starting ast step 2, 3, or 4 rather
> than
> > step 1.
>
> I can't find a message from you in any existing OpenMP-related
> threads. Perhaps you are referring to this
> (
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121105/067626.html
> )
> message in CilkPlus thread?


No no, I agree Cilk Plus is a totally different discussion and the points
there aren't relevant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121218/e33dfdf5/attachment.html>


More information about the cfe-commits mailing list