Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Alp Toker <alp <at> nuanti.com>
Subject: Future of the LLVM OpenMP runtime
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Tuesday 25th February 2014 23:13:54 UTC (over 3 years ago)
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
 
CD: 3ms