[cfe-dev] moving the clang-omp merge along
Andrey Bokhanko
andreybokhanko at gmail.com
Fri May 30 03:00:06 PDT 2014
Chandler,
Thanks for the encouragement and the additional suggestions! -- we can
always rely on you to keep us busy. :-)
> 3) we need a good switch in Clang to use iomp (I know you or someone on
the patch thread worked on this, did it land? if so, done!)
Yes, this is done -- see Alexey's message.
Andrey
On Thu, May 29, 2014 at 6:03 PM, Chandler Carruth <chandlerc at google.com>
wrote:
>
> On Thu, May 29, 2014 at 6:46 AM, Andrey Bokhanko <andreybokhanko at gmail.com
> > wrote:
>
>> While we are on the topic, let me update on some other things happening
>> in responce to other issues highlighted by Chandler:
>>
>
> I just wanted to say, I am very happy to see progress starting here. =]
> All of my comments below are meant to help the effort move faster and deal
> better with the LLVM project.
>
>
>> - This library is not being developed as an active part of the LLVM
>> community, even if it is checked into SVN as part of the LLVM project and
>> under its license. See r197914 where there is a code drop of many months
>> worth of development with *no* change log, attribution, information, or
>> other participation in any part of the community.
>>
>> This is changing, and many developers joining the whole OpenMP in clang
>> support effort. I can say that Michael Wong and many of his colleagues from
>> IBM are involved; Eric Stotzer and his colleagues from TI are involved;
>> Barbara Chapman and her group from UofHouston is involved; Guansong Zhang
>> from AMD is involved. Obviously, Hal Finkel, Chris Bergstrom, Steve Noonan
>> and many others continue to be actively involved as well.
>>
>> Take a look at the recent activity in openmp-dev mailing list. More to
>> come.
>>
>
> Pretty happy about this, and looking forward to more. Some things that
> would be helpful (IMO, others may disagree) to start looking into how/when
> to adopt or integrate:
>
> - Start more closely following the LLVM developer policy around code
> review and small, incremental patches and development.
> - Maybe use code review tools like Phabricator? Dunno what would be
> needed to make this work well, probably some stuff...
> - Check that the codebase compiles with the same host toolchain baseline
> as the rest of the LLVM project[1]
> - Maybe work out a plan toward generally conforming with the coding
> standards[2] where applicable?
>
>
>>
>> It is buildable with clang now. Moreover, regular buildbots, with both
>> gcc and clang, are running:
>>
>> http://lab.llvm.org:8011/builders/libiomp5-gcc-x86_64-linux-debian
>> http://lab.llvm.org:8011/builders/libiomp5-clang-x86_64-linux-debian
>>
>
> Just want to say, this in particular is fantastic.
>
>
>> - The build system is totally disjoint from LLVM's, in fact it is an
>> entirely custom Perl build system that is unlike anything in use by the
>> LLVM project.
>>
>> We started to work on improving build system. Stay tuned.
>>
>
> Very cool. I would look closely at the compiler-rt and libc++ CMake
> builds. Hopefully useful.
>
>
>> - There are *zero tests* in the open source repository!!!! This is even
>> called out in the original submission and on the primary website. We
>> simply
>> *cannot* ship and link against a runtime library which has no tests!
>>
>> University of Houston contributed OpenUH test suite:
>> http://lists.cs.uiuc.edu/pipermail/openmp-commits/2014-May/000019.html.
>> Sunita Chandrasekaran from the University works on integrating this suite
>> into LLVM test system.
>>
>> BTW, any advice with how to approach this would be *much* appreciated!
>>
>
> I think the right way to go is something along the lines of the ASan (in
> compiler-rt) lit tests, but maybe others have a better idea. I agree that
> testing here is hard.
>
>
>> - No part of this library has gone through an LLVM release process either,
>> not even as a "new" or "beta" project.
>>
>> Aha! So, you support inclusion of openmp (library, not compiler) in 3.5
>> as well? :-)
>>
>
> Hehe, I see what you did there.
>
> I do genuinely support it going through the release process, but I think
> that there are two things that need to be pretty solid first:
>
> 1) the build system work probably needs to be pretty solid. i'd be happy
> with support on par with compiler-rt or libc++ in CMake...
> 2) the test suite needs to be at least reasonably well integrated so
> release testers actually hit it and exercise the code
> 3) we need a good switch in Clang to use iomp (I know you or someone on
> the patch thread worked on this, did it land? if so, done!)
>
> Maybe others have other thoughts, but I think those three are my key ones.
>
> Anyways, thanks for the clarification and all the hard work on this stuff.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140530/9ce697d8/attachment.html>
More information about the cfe-dev
mailing list