This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [fortran,patch] BLAS-enabled matmul


FX Coudert wrote:
Now there's one thing slightly subtle about all this: suppose a user compiles some code that calls DGEMM, and forgets to link in his favorite BLAS library. Well, the program will compile and link fine, because we provided a symbol called dgemm_ in our libgfortran_blas library. But since this later is only a minimalist implementation, it does not handle all possibles cases (for example, it asserts that alpha=1 and beta=0), so this is very bad. To avoid that, I created a symbol libgfortran_called_blas in libgfortran, that is set to 1 before every BLAS call initiated by our library, and is set back to 0 afterwards. Similarly, the ?gemm routines in libgfortran_blas first to check if libgfortran_called_blas has value 1, else issue a runtime error message explaining the situation. I'm not happy with this situation, but couldn't think of a better way to handle this.

A couple of other related problems: What if someone just has a code that calls DGEMM, and _does_ remember to link in their favorite BLAS library? My impression is that your patch will break the way this would normally work, because the only way to link it without symbol clashes would be to go through explicitly wrapping it in -fexternal-blas, rather than simply linking it as they would any other library.


Also, this libgfortran_called_blas variable doesn't sound especially thread-safe.

If you have any idea, please share it!

An off-the-cuff idea that probably will get shot down:


To avoid all possible conflicts with user calls to dgemm_ and the like, don't use the BLAS names in our library. Instead, use names like dgemm_libgfortran (or something more appropriate) instead, and have our library call those.

Then, create two different libraries that provide these symbols. One of them is based on yours, and provides a minimal BLAS-like implementation. The other (called libgfortran_external_blas.c, perhaps) just passes the calls through to a "real" BLAS. If the -fexternal_blas option is used, the latter library is linked in, otherwise, the former is linked in.

This does have the disadvantage of adding another level of indirection to any calls to an external BLAS library, though.

- Brooks


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]