[cfe-dev] Future of the LLVM OpenMP runtime

[Cownie, James H]

> Now that we've kick-started the LLVM OpenMP runtime discussion, I want to make a concrete proposal
> to get a test suite up and running for the LLVM OpenMP runtime. I don't think the current setup 
> as an LLVM subproject is sustainable going forward without some form of testing support, automated
> or otherwise.

> The motivation: It's difficult to make changes to the source without some way to see if a commit breaks
> features or indeed works at all. This has a chilling effect on contributions -- without means to test
> changes the only verification strategy is visual inspection and finger crossing which isn't really
> a viable way to develop platform libraries.

I agree with all of that!

> My understanding is that the proprietary OpenMP runtime test suite at Intel contains customer code so
> there's little prospect of getting released for use within LLVM. So we can rule that out.

Correct. It *may* contain code snippets from customers for regression testing, and we have lawyers, so
even "may" is enough to seriously worry them. Attempting to audit it would be such a big job that
starting from somewhere else is likely to be more productive.

> As such I'd like to propose that we set aside a few days, perhaps with developers from Nuanti
> and Intel and anyone else who wants to lend a hand, to adapt a branch of the libgomp test suite to be
> hosted externally, that can be used to regression test the LLVM OpenMP runtime. 
> This shouldn't be much work given that the libraries are ABI/API-compatible and will at least
> show a way forward.

Another potential solution would be to take the validation suite from the OpenUH compiler 
http://web.cs.uh.edu/~openuh/download/ (which is BSD licensed), and start to build a more
comprehensive set of tests from that. Since it is BSD I believe we could take it without asking, 
however I'd like to get an ACK from the authors before doing that.

The other issues to consider here are
1) Which compiler is used to compile the tests?. 
   Without the OpenMP support in clang we still don't have our own compiler that can do that, so 
   we'd presumably have to use gcc.
2) If we build the runtime with clang and run tests built with gcc we need to be aware that there will be
   a potential incompatibility, since gcc supports a 128 bit float, and clang/llvm don't. Therefore
   it is impossible to compile the support for 128 bit reductions (which exists in the runtime source)
   using clang. (Though gcc may not be calling the runtime to do reductions anyway, in which case the issue 
   is a more general one of test coverage).


-- Jim

James Cownie <james.h.cownie at intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438


-----Original Message-----
From: Alp Toker [mailto:alp at nuanti.com] 
Sent: Tuesday, February 25, 2014 11:14 PM
To: openmp-dev at dcs-maillist2.engr.illinois.edu
Cc: llvmdev at cs.uiuc.edu; clang-dev Developers; Cownie, James H; Hal Finkel; Dmitri Gribenko
Subject: Future of the LLVM OpenMP runtime

Now that we've kick-started the LLVM OpenMP runtime discussion, I want to make a concrete proposal to get a test suite up and running for the LLVM OpenMP runtime. I don't think the current setup as an LLVM subproject is sustainable going forward without some form of testing support, automated or otherwise.

The motivation: It's difficult to make changes to the source without some way to see if a commit breaks features or indeed works at all. This has a chilling effect on contributions -- without means to test changes the only verification strategy is visual inspection and finger crossing which isn't really a viable way to develop platform libraries.

My understanding is that the proprietary OpenMP runtime test suite at Intel contains customer code so there's little prospect of getting released for use within LLVM. So we can rule that out.

As for the prospect of growing a test suite organically, there's a very low level of activity in LLVM OpenMP SVN characterised by occasional Intel code drops by Jim and my own work to get ToT tree building and running, with the previous commit being in December. So it's clear that a test suite, even a small one, isn't going to just "show up" through casual effort.

As such I'd like to propose that we set aside a few days, perhaps with developers from Nuanti and Intel and anyone else who wants to lend a hand, to adapt a branch of the libgomp test suite to be hosted externally, that can be used to regression test the LLVM OpenMP runtime. 
This shouldn't be much work given that the libraries are ABI/API-compatible and will at least show a way forward.

 From a licensing point of view it'll be similar to the way we point clang users to external gcc documentation, or the way dragonegg plugs into external gcc builds -- the runtime sources themselves are unaffected other than a workflow change. I don't see alternatives but I'll open the floor to other suggestions keeping in mind that without tests the project is starting to look dead in the water.

(This mail touches on the OpenMP runtime that affects LLVM and clang so I'm copying in those lists.)

Alp.

--
http://www.nuanti.com
the browser experts

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.