[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] Future of the LLVM OpenMP runtime
From:       "Cownie, James H" <james.h.cownie () intel ! com>
Date:       2014-02-26 10:29:38
Message-ID: 397D95928DECEF49983F5B237627E97822C1B56F () IRSMSX103 ! ger ! corp ! intel ! com
[Download RAW message or body]

> 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@intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
Tel: +44 117 9071438


-----Original Message-----
From: Alp Toker [mailto:alp@nuanti.com] 
Sent: Tuesday, February 25, 2014 11:14 PM
To: openmp-dev@dcs-maillist2.engr.illinois.edu
Cc: llvmdev@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.


_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic