This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [fortran,patch] BLAS-enabled matmul
- From: Mike Stump <mrs at apple dot com>
- To: FX Coudert <fxcoudert at gmail dot com>
- Cc: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>, gfortran <fortran at gcc dot gnu dot org>, patch <gcc-patches at gcc dot gnu dot org>, bmoses at stanford dot edu, drow at false dot org, paolo dot bonzini at lu dot unisi dot ch
- Date: Tue, 4 Apr 2006 12:41:33 -0700
- Subject: Re: [fortran,patch] BLAS-enabled matmul
- References: <44319954.7010203@gmail.com> <20060403222352.GA99591@troutmask.apl.washington.edu> <44322200.9@gmail.com>
On Apr 4, 2006, at 12:36 AM, FX Coudert wrote:
All in all, I'm most favorable to Brooks' suggestion that we have
libgfortran_blas and libgfortran_external_blas, i.e. an additional
function call.
I think one can do:
gnuc_my_blas = real_blas_name
and then have:
call gnuc_my_blas
and have it go directly to real_blas_name
on some assemblers (GNU as for example), if you want to optimize the
common case and eliminate the call/return overhead completely for
libgfortran_external_blas. I think this is non-portable, so you
might have to autoconf for it.
The only thing that I don't yet see clearly how to resolve is we
can avoid the user supplying the -fblas="-lblas" extra argument,
and simply link in its blas library by "-lblas".
I'm not sure I followed that exactly, but, if you want to add a
linker option on the basis of a flag to the compiler:
%{fprofile-arcs|fprofile-generate|coverage|fcreate-profile:-lgcov}
is one such example (target from gcc.c).
You can also do the inverse:
%{!nostdlib:%(link_gcc_math)}
So, something like:
%{fblas:-lblas}
though, if you want to have configure figure out the library name and
pass it to the building of the file that has this spec, it'd just be
a little more work.