[fortran,patch] BLAS-enabled matmul
Mon Apr 3 23:33:00 GMT 2006
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
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.
More information about the Gcc-patches