Richard Biener wrote:
> This adds recognition of [sd]axpy and [sd]dot computing partitions
> to loop distribution (as an example for a moderately complex kernel
> and one kernel involving a reduction).
>
> To make this a reality we have to control this by an option
> (-fblas?) and we have to settle to an ABI we rely on (trailing
> underscore, argument passing conventions and what integer type
> to use). "Official" CBLAS uses f2c and f2c.h to define the ABI.
gfortran (since GCC 4.3) has -fexternal-blas to convert MATMUL to
BLAS calls. It additionally has -fblas-matmul-limit=n (default: 30)
to avoid calls to the library for small arrays. (I don't recall
what happens if the size is unknown.) I believe that gfortran's ABI
is used - and I don't recall any bug reports related to that ABI
choice. (On the other hand, the number of -fexternal-blas users
is probably small.)
[In principle, dot_product also exists in Fortran 90+ and could
be handled in the FE as well.]
For the ABI, one has essentially the choice between platform ABI
(i.e. what gfortran uses by default) and f2c ABI (which several other
Fortran compilers use by default). My impression is that there is not
much of an ABI difference: Most compilers generate lower-case procedure
names, followed by a single underscore. Combining gfortran (with the
default -fno-f2c) with vendor LAPACK/BLAS libraries usually works
flawlessly. As some vendor libaries are compiled with gfortran (i.e.
not using f2c semantics) while vendor libraries use a different
(e.g. their own) compiler (which might use f2c ABI). Hence, there is
no natural choice for the ABI.
Regarding the ABI (platform ABI vs f2c) one has to be careful with:
* Functions returning complex numbers.
* On PowerPC (?) with complex numbers in general
(namely whether struct{float re, im} and _Complex float are ABI
compatible or not)
* Functions returning single precision (which f2c returns as double
precision)
* Functions returning logical values (like LAPACK's lsame; other
compilers might use different numbers than 1 for true, which is
not compatible with GCC's negation [!f() / .not.f() might stay
true for (-1) if handled as Boolean and not as int]).
* Second underscore (although my impression is that most compilers
have a single one by default).
See also
http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html#index-ff2c-238
For the BLAS routines in question, only complex numbers might be
problematic - at least on a very small set of systems (PowerPC).
In general: I think it can be a useful feature. However, I am not
sure that many users will use it. (Obstacle: They have to
know/remember that this exists, they have to have a code that can
profit from it, they need a vendor lib and they don't want to call
BLAS directly themselves.)
Tobias
