Re: [fortran,patch] BLAS-enabled matmul

[Brooks Moses <bmoses at stanford dot edu>]

Daniel Jacobowitz wrote:
> On Mon, Apr 03, 2006 at 11:53:24PM +0200, FX Coudert wrote:
> > 2. if -fexternal-blas is specified, its argument is added instead of 
> > -lgfortran_blas, but everything else from point 1 is still valid; 
> > append_blas() breaks the space-separated words in
> > -fexternal-blas argument before appending them to the arguments. As for 
> > the order of linking, -lgfortran still needs to be added after the 
> > external blas library, because if the external library was compiled with 
> > gfortran, it might have some libgfortran symbols referred in it :)
>
> This is pretty nasty.  If I were designing a command line interface for
> this, it would just be "-fexternal-blas disables inclusion of the
> default libgfortran_blas.a".  Can't we get that to work?  Maybe with
> --start-group and --end-group?

That does sound clearer, yes.  I gather that what you mean is that the 
-fexternal-blas option doesn't take an argument, and the user supplies 
other options (-lmy_blas_library, or whatever) in the usual way to 
actually link in the BLAS library?

I think this would combine well in combination with my other suggestion, 
too -- the explanation there would instead be "-fexternal_blas redirects 
use of some matrix intrinsics to external BLAS calls" or something like 
that.

----

One other thought, which the "if the external library was compiled with 
gfortran, it might have some libgfortran symbols referred in it" comment 
brought up upon rereading: We need to make sure that this process does 
not prevent compiling BLAS libraries on gfortran!

Ideally, it would also not prevent compiling a partial BLAS library for 
development purposes -- e.g., code that includes a DGEMM subroutine, but 
not a ZGEMM one.  The current version would, I think, either complain 
about a dgemm_ symbol clash or an undefined zgemm_ symbol, depending on 
the option chosen.

- Brooks