LLVM Euro 2015 Workshop Summary & Discussion

[John Leidel]

All, I wanted to post a a brief summary and discussion topic following last week's LLVM Euro conference.  Our Flang workshop was quite successful.  The workshop was well attended and the discussion was quite lively.  I'll summarize the discussion points as follows: 

- There was resounding support for the Flang project overall.  It was very well received by the LLVM community members.  

- There was significant support for promoting the Flang project to an official LLVM sub-project.  This implies that the source code would move under the LLVM SVN hosting and the mailing lists would be promoted to the UIUC majordomo.  

- There are a number of interesting licensing issues associated with Flang.  Many of the legacy open source Fortran codes (see Netlib) have bizarre or unspecified licenses.  

- The major gating factor at this point appears to be sourcing the rebased Flang on LLVM trunk.  (more discussion on this later)

All in all, I was very impressed by the community response to the workshop.  I would like to again thank Carlo Bertolli for all his diligent efforts in organizing the workshop.  I would also like to thank all our speakers for raising their support and community awareness for Flang.  

Best Regards, 

John Leidel

[Jeff Hammond]

Why does the Netlib license matter?  Is this because you want to call BLAS for the linear algebra intrinsics?  Why not just make calls to the BLAS API if the symbols can be found (i.e. look in default places and/or use the path the user specifies at compile time)?

In any case, MATMUL is the only call that really warrants a library implementation.  The compiler will likely beat BLAS1 for e.g. DOT_PRODUCT and other bandwidth-limited data-parallel operations.

For what it's worth, the use of MATMUL in the wild is extremely low.  I have literally never seen it used, and I have read a decent amount of Fortran code over the years.  Everyone I know calls _GEMM, because that ensures the desired implementation is used.  I know IBM and Intel compilers both automatically hook ESSL and MKL, respectively, but I don't think gfortran does anything good here (unfortunately, as it certainly could), so defense HPC programming says it cannot be used.

Best,

Jeff

[John Leidel]

Jeff, the netlib repository has a wealth of Fortran code that we would like to leverage for a potential test suite.  I'm less worried about the specific hooks relative to BLAS and Lapack, but these codes represent interesting points by which we can get test coverage.  Unfortunately, there are a number of netlib packages (several of which are relevant) that don't contain explicit licenses.  We want to ensure whatever we do for the 'flang' test suite adheres the necessary LLVM/UIUC BSD style license guidelines.  There are a number of tests in the application test-suite that simply have placeholders & scripts for the code (SPEC) rather than including the source.  

cheers

john 

--
You received this message because you are subscribed to the Google Groups "flang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flang-dev+...@googlegroups.com.
To post to this group, send email to flan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flang-dev/1ed601e9-7fab-44a2-9774-6589ae004fc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeff Hammond]

LAPACK is BSD-3 (http://www.netlib.org/lapack/LICENSE or
http://www.netlib.org/lapack/LICENSE.txt, which are the same terms but
with slightly different copyright holders). Since the LAPACK
distribution contains BLAS, I think that means BLAS is also BSD-3.

I think you just have to ask Jack to make the BSD-3 license more
systematic in Netlib. I'm sure that he would be willing to help in
this regard.

FWIW, Global Arrays used to have an ambiguous license but IBM lawyers
insisted on a real one (or so the story goes - I was not party to
these events), and thus PNNL created one. I'd not be surprised at all
if the reason LAPACK is BSD-3 is because one or more vendors requested
it.

Best,

Jeff

--
Jeff Hammond
jeff.s...@gmail.com
http://jeffhammond.github.io/