[Openmp-dev] LLVM coding conventions an the OpenMP runtime

Tue Aug 9 01:37:45 PDT 2016

> -----Original Message-----
> From: C Bergström [mailto:cbergstrom at pathscale.com]
> Sent: Tuesday, August 09, 2016 10:23 AM
> To: Hahnfeld, Jonas
> Cc: Wilmarth, Terry L; LLVM-OpenMP (openmp-dev at lists.llvm.org)
> Subject: Re: [Openmp-dev] LLVM coding conventions an the OpenMP
> runtime
> 
> Pragmatically and just my view - If the research is open and there's a plan to
> integrate it back I'm empathetic. If it's closed and just an outside fork, I don't
> care what you do and it shouldn't block an open source project. Long term
> plans start somewhere - so even if this clean-up doesn't happen now, I think
> it makes sense to figure out who will impact and break it into small steps.

Some research ends up being standardized and is given back, but I don't want to discuss this here.
This may be a weak argument but I think it's valuable to have it in mind...

> 
> Again just my view, but I strongly dislike some of the coding practices being
> employed. I'd love to see some things which I consider "fugly hacks"
> removed.

If that's anything else than "cosmetic candy" I think nobody will speak up against patches ;-)

> 
> In terms of the actual logistics - if the entire clean-up is done as a single
> commit - it should be fairly easy for that to rebase against an out-of-tree
> fork. Worst case the research just isn't in sync with upstream, but not all
> research projects track git HEAD or svn ToT..

Disagree here, what I've seen so far: Neither git nor SVN can easily handle whitespace reformatting on rebase or merge.

Cheers,
Jonas

> 
> 
> 
> On Tue, Aug 9, 2016 at 4:15 PM, Hahnfeld, Jonas <Hahnfeld at itc.rwth-
> aachen.de> wrote:
> > As already stated I think that we currently have a consistent coding style
> inside the runtime.
> > I agree that aligning to LLVM/Clang should be the long-term goal but
> > IMO "cosmetic candy" doesn't warrant a full reformat in place. (I'm
> > supported here by the LLVM coding standard itself!)
> >
> > To put up more practical reasons: There is quite some research and
> experimental implementation based on this repository.
> > It will be hard as hell to update and work with them when we touch every
> single line with whitespace throughout the code.
> >
> > Regards,
> > Jonas
> >
> >> -----Original Message-----
> >> From: C Bergström [mailto:cbergstrom at pathscale.com]
> >> Sent: Tuesday, August 09, 2016 8:33 AM
> >> To: Hahnfeld, Jonas
> >> Cc: Wilmarth, Terry L; LLVM-OpenMP (openmp-dev at lists.llvm.org)
> >> Subject: Re: [Openmp-dev] LLVM coding conventions an the OpenMP
> >> runtime
> >>
> >> I can understand why Intel would be strongly against a larger format,
> >> can you give some data points for your use case? Besides just a
> >> "feeling" what's the rationale for strongly against
> >>
> >> Thanks
> >>
> >> On Tue, Aug 9, 2016 at 2:28 PM, Hahnfeld, Jonas <Hahnfeld at itc.rwth-
> >> aachen.de> wrote:
> >> > Chris,
> >> >
> >> > I didn't: I'm currently in favor of NOT doing the conversion as
> >> > also said in
> >> the coding standards. Full stop.
> >> >
> >> > However I just wanted to express that I'm not against (more precisely:
> >> strongly support) to do the reformatting when moving the code base
> >> anyway.
> >> > I agree that this is a different matter and has to be discussed
> >> > separately but
> >> it may be a compromise on this discussion.
> >> >
> >> > Thanks,
> >> > Jonas
> >> >
> >> >> -----Original Message-----
> >> >> From: C Bergström [mailto:cbergstrom at pathscale.com]
> >> >> Sent: Tuesday, August 09, 2016 8:20 AM
> >> >> To: Hahnfeld, Jonas
> >> >> Cc: Wilmarth, Terry L; LLVM-OpenMP (openmp-dev at lists.llvm.org)
> >> >> Subject: Re: [Openmp-dev] LLVM coding conventions an the OpenMP
> >> >> runtime
> >> >>
> >> >> Can we not compound two distinct and unrelated issues. Proper code
> >> >> formatting impacts everything now and there's no blocker on it
> >> >> needing to be moved.
> >> >>
> >> >> I'm strongly in favor of going towards a consistent style which is
> >> >> similar to llvm/clang. However, if others feel strongly that it's
> >> >> disruptive I think we should be sensitive to their views. I
> >> >> realize that Intel is maintaining two trees already and I wouldn't
> >> >> want to make their job any harder, just for the sake of cosmetic candy.
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Aug 9, 2016 at 2:07 PM, Hahnfeld, Jonas via Openmp-dev
> >> >> <openmp- dev at lists.llvm.org> wrote:
> >> >> > Hi Terry,
> >> >> >
> >> >> >
> >> >> >
> >> >> > IMO we should for now stay with the current coding standard as
> >> >> > it is currently consistently used within the runtime (4 spaces
> >> >> > indention, naming etc.).
> >> >> >
> >> >> >
> >> >> >
> >> >> > That said, there was a proposal of moving the OpenMP runtime
> >> >> > into parallel_libs (which I completely support btw).
> >> >> >
> >> >> > If the whole code is then recommitted anyway, I think it is safe
> >> >> > to do the cleanups in that process.
> >> >> >
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Jonas
> >> >> >
> >> >> >
> >> >> >
> >> >> > From: Openmp-dev [mailto:openmp-dev-bounces at lists.llvm.org]
> On
> >> >> Behalf
> >> >> > Of Wilmarth, Terry L via Openmp-dev
> >> >> > Sent: Monday, August 08, 2016 6:18 PM
> >> >> > To: openmp-dev at lists.llvm.org
> >> >> > Subject: [Openmp-dev] LLVM coding conventions an the OpenMP
> >> runtime
> >> >> >
> >> >> >
> >> >> >
> >> >> > Hello,
> >> >> >
> >> >> > We are considering the possibility of doing a conversion of the
> >> >> > OpenMP runtime code to better comply with the LLVM coding
> >> >> > conventions in the
> >> >> > mid- to late-September time frame.  This would most likely
> >> >> > involve running the code through clang-format with the LLVM
> >> >> > style option, as well as correcting any other glaring violations
> >> >> > of the coding
> >> conventions.
> >> >> >
> >> >> >
> >> >> >
> >> >> > It would probably *not* involve renaming anything to adhere to
> >> >> > naming conventions.
> >> >> >
> >> >> >
> >> >> >
> >> >> > However, we’ve noted that LLVM’s coding standards document says
> >> the
> >> >> > following:
> >> >> >
> >> >> >
> >> >> >
> >> >> > “There are some conventions that are not uniformly followed in
> >> >> > the code base (e.g. the naming convention). This is because they
> >> >> > are relatively new, and a lot of code was written before they
> >> >> > were put in place. Our long term goal is for the entire codebase
> >> >> > to follow the convention, but we explicitly do not want patches
> >> >> > that do large-scale reformating of existing code. On the other
> >> >> > hand, it is reasonable to rename the methods of a class if
> >> >> > you’re about to change it in some other way. Just do the
> >> >> > reformating as a separate commit from the functionality change.“
> >> >> >
> >> >> >
> >> >> >
> >> >> > This would definitely be a large-scale reformatting.
> >> >> >
> >> >> >
> >> >> >
> >> >> > So I just wanted to get some feedback on this before we make
> >> >> > plans to do this.
> >> >> >
> >> >> >
> >> >> >
> >> >> > Thanks!
> >> >> >
> >> >> > Terry
> >> >> >
> >> >> > --
> >> >> > Terry L. Wilmarth
> >> >> > terry.l.wilmarth at intel.com   217/403-4251
> >> >> > Intel/SSG/DPD/TCAR/RAD/Threading Runtimes
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > 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/20160809/f3789c98/attachment.bin>