2021-06-15 17:06:23 +02:00
|
|
|
# $NetBSD: Makefile.common,v 1.6 2021/06/15 15:06:23 thor Exp $
|
2020-11-05 17:31:45 +01:00
|
|
|
#
|
|
|
|
|
# used by math/openblas_pthread/Makefile
|
|
|
|
|
# used by math/openblas_openmp/Makefile
|
|
|
|
|
# used by math/openblas/Makefile
|
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
2021-06-15 06:41:51 +02:00
|
|
|
# used by math/openblas64_pthread/Makefile
|
|
|
|
|
# used by math/openblas64_openmp/Makefile
|
|
|
|
|
# used by math/openblas64/Makefile
|
2020-11-05 17:31:45 +01:00
|
|
|
#
|
|
|
|
|
# This is the common Makefile for OpenBLAS builds. It depends on
|
|
|
|
|
# OPENBLAS_VARIANT = (openblas|openblas_pthread|openblas_openmp)
|
|
|
|
|
# being set.
|
|
|
|
|
|
|
|
|
|
DISTNAME= OpenBLAS-${OPENBLAS_VERSION}
|
|
|
|
|
PKGNAME= ${OPENBLAS_VARIANT}-${OPENBLAS_VERSION}
|
|
|
|
|
DIST_SUBDIR= openblas-${OPENBLAS_VERSION}
|
|
|
|
|
CATEGORIES= math
|
|
|
|
|
MASTER_SITES= ${MASTER_SITE_GITHUB:=xianyi/} \
|
|
|
|
|
http://www.netlib.org/lapack/timing/
|
|
|
|
|
DISTFILES= ${DISTNAME}.tar.gz ${LARGE_FILE} ${TIMING_FILE}
|
|
|
|
|
LARGE_FILE= large.tgz
|
|
|
|
|
TIMING_FILE= timing.tgz
|
|
|
|
|
GITHUB_PROJECT= OpenBLAS
|
|
|
|
|
GITHUB_TAG= v${OPENBLAS_VERSION}
|
|
|
|
|
|
|
|
|
|
DISTINFO_FILE= ${.CURDIR}/../../math/openblas/distinfo
|
|
|
|
|
PATCHDIR= ${.CURDIR}/../../math/openblas/patches
|
|
|
|
|
|
|
|
|
|
HOMEPAGE= https://github.com/xianyi/OpenBLAS
|
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
2021-06-15 06:41:51 +02:00
|
|
|
COMMENT= Optimized BLAS library based on GotoBLAS2 (variant ${OPENBLAS_VARIANT})
|
2020-11-05 17:31:45 +01:00
|
|
|
LICENSE= modified-bsd
|
|
|
|
|
|
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
2021-06-15 06:41:51 +02:00
|
|
|
# Darwin has a .so/.dylib PLIST issue
|
|
|
|
|
# Untested on other platforms
|
|
|
|
|
ONLY_FOR_PLATFORM= Linux-*-* NetBSD-*-*
|
|
|
|
|
|
2020-11-05 17:31:45 +01:00
|
|
|
USE_LANGUAGES= c fortran
|
|
|
|
|
USE_TOOLS+= gmake perl:build
|
|
|
|
|
|
|
|
|
|
NO_CONFIGURE= yes
|
|
|
|
|
|
|
|
|
|
TEST_TARGET= tests
|
|
|
|
|
|
|
|
|
|
# Also set compilers explicitly, overriding Makefile.rule
|
|
|
|
|
MAKE_FLAGS+= CC=${CC:Q}
|
|
|
|
|
MAKE_FLAGS+= CXX=${CXX:Q}
|
|
|
|
|
MAKE_FLAGS+= FC=${FC:Q}
|
|
|
|
|
|
|
|
|
|
# You may override the autodetected thread count limit.
|
|
|
|
|
# Default is detected from build host, which may differ from run host.
|
|
|
|
|
BUILD_DEFS+= OPENBLAS_THREAD_LIMIT
|
|
|
|
|
|
|
|
|
|
.include "../../mk/bsd.prefs.mk"
|
|
|
|
|
|
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
2021-06-15 06:41:51 +02:00
|
|
|
# Using conservative default of 32 threads as that matches the
|
|
|
|
|
# limit for related stack arrays in OpenBLAS. Might raise it
|
|
|
|
|
# in future, anyway. There some memory usage/efficiency tradeoff
|
|
|
|
|
# when this number is excessively high.
|
|
|
|
|
OPENBLAS_THREAD_LIMIT?= 32
|
2020-11-05 17:31:45 +01:00
|
|
|
.if !empty(OPENBLAS_THREAD_LIMIT)
|
|
|
|
|
MAKE_FLAGS+= NUM_THREADS=${OPENBLAS_THREAD_LIMIT:Q}
|
|
|
|
|
.endif
|
|
|
|
|
BENCHMARK_MAXTHREADS?= 8
|
|
|
|
|
|
2021-06-15 17:06:23 +02:00
|
|
|
.if empty(LP64PLATFORMS:@.PLAT.@${MACHINE_PLATFORM:M${.PLAT.}}@)
|
2020-11-05 17:31:45 +01:00
|
|
|
MAKE_FLAGS+= BINARY32=1
|
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
2021-06-15 06:41:51 +02:00
|
|
|
. if !empty(OPENBLAS_VARIANT:M*64*)
|
|
|
|
|
PKG_FAIL_REASON+= "${OPENBLAS_VARIANT} incompatible with non-64-bit platform"
|
|
|
|
|
. endif
|
2020-11-05 17:31:45 +01:00
|
|
|
.else
|
|
|
|
|
MAKE_FLAGS+= BINARY64=1
|
|
|
|
|
.endif
|
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
2021-06-15 06:41:51 +02:00
|
|
|
|
|
|
|
|
# Build with the C APIs, as do other optimized libraries.
|
|
|
|
|
#MAKE_FLAGS+= NO_CBLAS=0 NO_LAPACKE=0
|
2020-11-05 17:31:45 +01:00
|
|
|
|
|
|
|
|
# Separate headers and cmake stuff.
|
|
|
|
|
MAKE_FLAGS+= OPENBLAS_INCLUDE_DIR=${PREFIX}/include/${OPENBLAS_VARIANT}
|
|
|
|
|
MAKE_FLAGS+= OPENBLAS_CMAKE_DIR=${PREFIX}/lib/cmake/${OPENBLAS_VARIANT}
|
|
|
|
|
|
2021-06-15 17:06:23 +02:00
|
|
|
# Settled on no sumbol suffix for 64 bit.
|
math/openblas: update to version 0.3.15
This includes a rework of our patchery with the hope of upstreaming a good deal
of it.
These are the upstream changes since 0.3.10:
Version 0.3.15
2-May-2021
common:
- imported improvements and bugfixes from Reference-LAPACK 3.9.1
- imported LAPACKE interface fixes from Reference-LAPACK PRs 534 + 537
- fixed a problem in the cpu detection of 0.3.14 that prevented cross-compilation
- fixed a sequence problem in the generation of softlinks to the library in GMAKE
RISC V:
- fixed compilation on RISCV (missing entry in getarch)
- fixed a potential division by zero in CROTG and ZROTG
POWER:
- fixed LAPACK testsuite failures seen with the NVIDIA HPC compiler
- improved CGEMM, DGEMM and ZGEMM performance on POWER10
- added an optimized ZGEMV kernel for POWER10
- fixed a potential division by zero in CROTG and ZROTG
x86_64:
- added support for Intel Control-flow Enforcement Technology (CET)
- reverted the DOMATCOPY_RT code to the generic C version
- fixed a bug in the AVX512 SGEMM kernel introduced in 0.3.14
- fixed misapplication of -msse flag to non-SSE cpus in DYNAMIC_ARCH
- added support for compilation of the benchmarks on older OSX versions
- fix propagation of the NO_AVX512 option in CMAKE builds
- fix compilation of the AVX512 SGEMM kernel with clang-cl on Windows
- fixed compilation of the CTESTs with INTERFACE64=1 (random faults on OSX)
- corrected the Haswell DROT kernel to require AVX2/FMA3 rather than AVX512
ARM:
- fixed a potential division by zero in CROTG and ZROTG
- fixed a potential overflow in IMATCOPY/ZIMATCOPY and the CTESTs
ARM64:
- fixed spurious reads outside the array in the SGEMM tcopy macro
- fixed a potential division by zero in CROTG and ZROTG
- fixed a segmentation fault in DYNAMIC_ARCH builds (reappeared in 0.3.14)
MIPS
- fixed a potential division by zero in CROTG and ZROTG
- fixed a potential overflow in IMATCOPY/ZIMATCOPY and the CTESTs
MIPS64:
- fixed a potential division by zero in CROTG and ZROTG
SPARC:
- fixed a potential division by zero in CROTG and ZROTG
====================================================================
Version 0.3.14
17-Mar-2021
common:
* Fixed a race condition on thread shutdown in non-OpenMP builds
* Fixed custom BUFFERSIZE option getting ignored in gmake builds
* Fixed CMAKE compilation of the TRMM kernels for GENERIC platforms
* Added CBLAS interfaces for CROTG, ZROTG, CSROT and ZDROT
* Improved performance of OMATCOPY_RT across all platforms
* Changed perl scripts to use env instead of a hardcoded /usr/bin/perl
* Fixed potential misreading of the GCC compiler version in the build scripts
* Fixed convergence problems in LAPACK complex GGEV/GGES (Reference-LAPACK #477)
* Reduced the stacksize requirements for running the LAPACK testsuite (Reference-LAPACK #335)
RISCV:
* Fixed compilation on RISCV (missing entry in getarch)
POWER:
* Fixed compilation for DYNAMIC_ARCH with clang and with old gcc versions
* Added support for compilation on FreeBSD/ppc64le
* Added optimized POWER10 kernels for SSCAL, DSCAL, CSCAL, ZSCAL
* Added optimized POWER10 kernels for SROT, DROT, CDOT, SASUM, DASUM
* Improved SSWAP, DSWAP, CSWAP, ZSWAP performance on POWER10
* Improved SCOPY and CCOPY performance on POWER10
* Improved SGEMM and DGEMM performance on POWER10
* Added support for compilation with the NVIDIA HPC compiler
x86_64:
* Added an optimized bfloat16 GEMM kernel for Cooperlake
* Added CPUID autodetection for Intel Rocket Lake and Tiger Lake cpus
* Improved the performance of SASUM,DASUM,SROT,DROT on AMD Ryzen cpus
* Added support for compilation with the NAG Fortran compiler
* Fixed recognition of the AMD AOCC compiler
* Fixed compilation for DYNAMIC_ARCH with clang on Windows
* Added support for running the BLAS/CBLAS tests on Windows
* Fixed signatures of the tls callback functions for Windows x64
* Fixed various issues with fma intrinsics support handling
ARM:
* Added support for embedded Cortex M targets via a new option EMBEDDED
ARMV8:
* Fixed the THUNDERX2T99 and NEOVERSEN1 DNRM2/ZNRM2 kernels for inputs with Inf
* Added support for the DYNAMIC_LIST option
* Added support for compilation with the NVIDIA HPC compiler
* Added support for compiling with the NAG Fortran compiler
====================================================================
Version 0.3.13
12-Dec-2020
common:
* Added a generic bfloat16 SBGEMV kernel
* Fixed a potentially severe memory leak after fork in OpenMP builds
that was introduced in 0.3.12
* Added detection of the Fujitsu Fortran compiler
* Added detection of the (e)gfortran compiler on OpenBSD
* Added support for overriding the default name of the library independently
from symbol suffixing in the gmake builds (already supported in cmake)
RISCV:
* Added a RISC V port optimized for C910V
POWER:
* Added optimized POWER10 kernels for SAXPY, CAXPY, SDOT, DDOT and DGEMV_N
* Improved DGEMM performance on POWER10
* Improved STRSM and DTRSM performance on POWER9 and POWER10
* Fixed segmemtation faults in DYNAMIC_ARCH builds
* Fixed compilation with the PGI compiler
x86:
* Fixed compilation of kernels that require SSE2 intrinsics since 0.3.12
x86_64:
* Added an optimized bfloat16 SBGEMV kernel for SkylakeX and Cooperlake
* Improved the performance of SASUM and DASUM kernels through parallelization
* Improved the performance of SROT and DROT kernels
* Improved the performance of multithreaded xSYRK
* Fixed OpenMP builds that use the LLVM Clang compiler together with GNU gfortran
(where linking of both the LLVM libomp and GNU libgomp could lead to lockups or
wrong results)
* Fixed miscompilations by old gcc 4.6
* Fixed misdetection of AVX2 capability in some Sandybridge cpus
* Fixed lockups in builds combining DYNAMIC_ARCH with TARGET=GENERIC on OpenBSD
ARM64:
* Fixed segmemtation faults in DYNAMIC_ARCH builds
MIPS:
* Improved kernels for Loongson 3R3 ("3A") and 3R4 ("3B") models, including MSA
* Fixed bugs in the MSA kernels for CGEMM, CTRMM, CGEMV and ZGEMV
* Added handling of zero increments in the MSA kernels for SSWAP and DSWAP
* Added DYNAMIC_ARCH support for MIPS64 (currently Loongson3R3/3R4 only)
SPARC:
* Fixed building 32 and 64 bit SPARC kernels with the SolarisStudio compilers
====================================================================
Version 0.3.12
24-Oct-2020
common:
* Fixed missing BLAS/LAPACK functions (inadvertently dropped during
the build system restructuring)
* Fixed argument conversion macro in LAPACKE_zgesvdq (LAPACK #458)
POWER:
* Added optimized SCOPY/CCOPY kernels for POWER10
* Increased and unified the default size of the GEMM BUFFER
* Fixed building for POWER10 in DYNAMIC_ARCH mode
* POWER10 compatibility test now checks binutils version as well
* Cleaned up compiler warnings
x86_64:
* corrected compiler version checks for AVX2 compatibility
* added compiler option -mavx2 for building with flang
* fixed direct SGEMM pathway for small matrix sizes (broken by
the code refactoring in 0.3.11)
* fixed unhandled partial register clobbers in several kernels
for AXPY,DOT,GEMV_N and GEMV_T flagged by gcc10 tree-vectorizer
ARMV8:
* improved Apple Vortex support to include cross-compiling
====================================================================
Version 0.3.11
17-Oct-2020
common:
* API change:
the newly added BFLOAT16 functions were renamed to use the
letter "B" instead of "H" to avoid potential confusion with
the IEEE "half precision float" type, i.e. the 0.3.10
SHGEMM is now SBGEMM and the corresponding build option
was changed from "BUILD_HALF" to "BUILD_BFLOAT16".
* Reduced the default BLAS3_MEM_ALLOC_THRESHOLD (used as an upper
limit for placing temporary arrays on the stack) to be compatible
with a stack size of 1mb (as imposed by the JAVA runtime library)
* Added mixed-precision dot function SBDOT and utility functions
shstobf16, shdtobf16, sbf16tos and dbf16tod to convert between
single or double precision float arrays and bfloat16 arrays
* Fixed prototypes of LAPACK_?ggsvp and LAPACK_?ggsvd functions
in lapack.h
* Fixed underflow and rounding errors in LAPACK SLANV2 and DLANV2
(causing miscalculations in e.g. SHSEQR/DHSEQR, LAPACK issue #263)
* Fixed workspace calculation in LAPACK ?GELQ (LAPACK issue #415)
* Fixed several bugs in the LAPACK testsuite
* Improved performance of TRMM and TRSM for certain problem sizes
* Fixed infinite recursions and workspace miscalculations in ReLAPACK
* CMAKE builds no longer require pkg-config for creating the .pc file
* Makefile builds no longer misread NO_CBLAS=0 or NO_LAPACK=0 as
enabling these options
* Fixed detection of gfortran when invoked through an mpi wrapper
* Improve thread reinitialization performance with OpenMP after a fork
* Added support for building only the subset of the library required
for a particular precision by specifying BUILD_SINGLE, BUILD_DOUBLE
* Optional function name prefixes and suffixes are now correctly
reflected in the generated cblas.h
* Added CMAKE build support for the LAPACK and multithreading tests
POWER:
* Added optimized support for POWER10
* Added support for compiling for POWER8 in 32bit mode
* Added support for compilation with LLVM/clang
* Added support for compilation with NVIDIA/PGI compilers
* Fixed building on big-endian POWER8
* Fixed miscompilation of ZDOTC by gcc10
* Fixed alignment errors in the POWER8 SAXPY kernel
* Improved CPU detection on AIX
* Supported building with older compilers on POWER9
x86_64:
* Added support for Intel Cooperlake
* Added autodetection of AMD Renoir/Matisse/Zen3 cpus
* Added autodetection of Intel Comet Lake cpus
* Reimplemented ?sum, ?dot and daxpy using universal intrinsics
* Reset the fpu state before using the fpu on Windows as a workaround
for a problem introduced in Windows 10 build 19041 (a.k.a. SDK 2004)
* Fixed potentially undefined behaviour in the dot and gemv_t kernels
* Fixed a potential segmentation fault in DYNAMIC_ARCH builds
* Fixed building for ZEN with PGI/NVIDIA and AMD AOCC compilers
ARMV7:
* Fixed cpu detection on BSD-like systems
ARMV8:
* Added preliminary support for Apple Vortex cpus
* Added support for the Cavium ThunderX3T110 cpu
* Fixed cpu detection on BSD-like systems
* Fixed compilation in -std=C18 mode
IBM Z:
* Added support for compiling with the clang compiler
* Improved GEMM performance on Z14
2021-05-29 21:57:21 +02:00
|
|
|
MAKE_FLAGS+= FIXED_LIBNAME=1
|
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
2021-06-15 06:41:51 +02:00
|
|
|
.if ${OPENBLAS_VARIANT} == openblas || ${OPENBLAS_VARIANT} == openblas64
|
2020-11-05 17:31:45 +01:00
|
|
|
MAKE_FLAGS+= USE_OPENMP=0 USE_THREAD=0 USE_LOCKING=1
|
|
|
|
|
BENCHMARK_ENV= USE_SIMPLE_THREADED_LEVEL3=1
|
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
2021-06-15 06:41:51 +02:00
|
|
|
.elif !empty(OPENBLAS_VARIANT:Mopenblas*_pthread)
|
math/openblas: update to version 0.3.15
This includes a rework of our patchery with the hope of upstreaming a good deal
of it.
These are the upstream changes since 0.3.10:
Version 0.3.15
2-May-2021
common:
- imported improvements and bugfixes from Reference-LAPACK 3.9.1
- imported LAPACKE interface fixes from Reference-LAPACK PRs 534 + 537
- fixed a problem in the cpu detection of 0.3.14 that prevented cross-compilation
- fixed a sequence problem in the generation of softlinks to the library in GMAKE
RISC V:
- fixed compilation on RISCV (missing entry in getarch)
- fixed a potential division by zero in CROTG and ZROTG
POWER:
- fixed LAPACK testsuite failures seen with the NVIDIA HPC compiler
- improved CGEMM, DGEMM and ZGEMM performance on POWER10
- added an optimized ZGEMV kernel for POWER10
- fixed a potential division by zero in CROTG and ZROTG
x86_64:
- added support for Intel Control-flow Enforcement Technology (CET)
- reverted the DOMATCOPY_RT code to the generic C version
- fixed a bug in the AVX512 SGEMM kernel introduced in 0.3.14
- fixed misapplication of -msse flag to non-SSE cpus in DYNAMIC_ARCH
- added support for compilation of the benchmarks on older OSX versions
- fix propagation of the NO_AVX512 option in CMAKE builds
- fix compilation of the AVX512 SGEMM kernel with clang-cl on Windows
- fixed compilation of the CTESTs with INTERFACE64=1 (random faults on OSX)
- corrected the Haswell DROT kernel to require AVX2/FMA3 rather than AVX512
ARM:
- fixed a potential division by zero in CROTG and ZROTG
- fixed a potential overflow in IMATCOPY/ZIMATCOPY and the CTESTs
ARM64:
- fixed spurious reads outside the array in the SGEMM tcopy macro
- fixed a potential division by zero in CROTG and ZROTG
- fixed a segmentation fault in DYNAMIC_ARCH builds (reappeared in 0.3.14)
MIPS
- fixed a potential division by zero in CROTG and ZROTG
- fixed a potential overflow in IMATCOPY/ZIMATCOPY and the CTESTs
MIPS64:
- fixed a potential division by zero in CROTG and ZROTG
SPARC:
- fixed a potential division by zero in CROTG and ZROTG
====================================================================
Version 0.3.14
17-Mar-2021
common:
* Fixed a race condition on thread shutdown in non-OpenMP builds
* Fixed custom BUFFERSIZE option getting ignored in gmake builds
* Fixed CMAKE compilation of the TRMM kernels for GENERIC platforms
* Added CBLAS interfaces for CROTG, ZROTG, CSROT and ZDROT
* Improved performance of OMATCOPY_RT across all platforms
* Changed perl scripts to use env instead of a hardcoded /usr/bin/perl
* Fixed potential misreading of the GCC compiler version in the build scripts
* Fixed convergence problems in LAPACK complex GGEV/GGES (Reference-LAPACK #477)
* Reduced the stacksize requirements for running the LAPACK testsuite (Reference-LAPACK #335)
RISCV:
* Fixed compilation on RISCV (missing entry in getarch)
POWER:
* Fixed compilation for DYNAMIC_ARCH with clang and with old gcc versions
* Added support for compilation on FreeBSD/ppc64le
* Added optimized POWER10 kernels for SSCAL, DSCAL, CSCAL, ZSCAL
* Added optimized POWER10 kernels for SROT, DROT, CDOT, SASUM, DASUM
* Improved SSWAP, DSWAP, CSWAP, ZSWAP performance on POWER10
* Improved SCOPY and CCOPY performance on POWER10
* Improved SGEMM and DGEMM performance on POWER10
* Added support for compilation with the NVIDIA HPC compiler
x86_64:
* Added an optimized bfloat16 GEMM kernel for Cooperlake
* Added CPUID autodetection for Intel Rocket Lake and Tiger Lake cpus
* Improved the performance of SASUM,DASUM,SROT,DROT on AMD Ryzen cpus
* Added support for compilation with the NAG Fortran compiler
* Fixed recognition of the AMD AOCC compiler
* Fixed compilation for DYNAMIC_ARCH with clang on Windows
* Added support for running the BLAS/CBLAS tests on Windows
* Fixed signatures of the tls callback functions for Windows x64
* Fixed various issues with fma intrinsics support handling
ARM:
* Added support for embedded Cortex M targets via a new option EMBEDDED
ARMV8:
* Fixed the THUNDERX2T99 and NEOVERSEN1 DNRM2/ZNRM2 kernels for inputs with Inf
* Added support for the DYNAMIC_LIST option
* Added support for compilation with the NVIDIA HPC compiler
* Added support for compiling with the NAG Fortran compiler
====================================================================
Version 0.3.13
12-Dec-2020
common:
* Added a generic bfloat16 SBGEMV kernel
* Fixed a potentially severe memory leak after fork in OpenMP builds
that was introduced in 0.3.12
* Added detection of the Fujitsu Fortran compiler
* Added detection of the (e)gfortran compiler on OpenBSD
* Added support for overriding the default name of the library independently
from symbol suffixing in the gmake builds (already supported in cmake)
RISCV:
* Added a RISC V port optimized for C910V
POWER:
* Added optimized POWER10 kernels for SAXPY, CAXPY, SDOT, DDOT and DGEMV_N
* Improved DGEMM performance on POWER10
* Improved STRSM and DTRSM performance on POWER9 and POWER10
* Fixed segmemtation faults in DYNAMIC_ARCH builds
* Fixed compilation with the PGI compiler
x86:
* Fixed compilation of kernels that require SSE2 intrinsics since 0.3.12
x86_64:
* Added an optimized bfloat16 SBGEMV kernel for SkylakeX and Cooperlake
* Improved the performance of SASUM and DASUM kernels through parallelization
* Improved the performance of SROT and DROT kernels
* Improved the performance of multithreaded xSYRK
* Fixed OpenMP builds that use the LLVM Clang compiler together with GNU gfortran
(where linking of both the LLVM libomp and GNU libgomp could lead to lockups or
wrong results)
* Fixed miscompilations by old gcc 4.6
* Fixed misdetection of AVX2 capability in some Sandybridge cpus
* Fixed lockups in builds combining DYNAMIC_ARCH with TARGET=GENERIC on OpenBSD
ARM64:
* Fixed segmemtation faults in DYNAMIC_ARCH builds
MIPS:
* Improved kernels for Loongson 3R3 ("3A") and 3R4 ("3B") models, including MSA
* Fixed bugs in the MSA kernels for CGEMM, CTRMM, CGEMV and ZGEMV
* Added handling of zero increments in the MSA kernels for SSWAP and DSWAP
* Added DYNAMIC_ARCH support for MIPS64 (currently Loongson3R3/3R4 only)
SPARC:
* Fixed building 32 and 64 bit SPARC kernels with the SolarisStudio compilers
====================================================================
Version 0.3.12
24-Oct-2020
common:
* Fixed missing BLAS/LAPACK functions (inadvertently dropped during
the build system restructuring)
* Fixed argument conversion macro in LAPACKE_zgesvdq (LAPACK #458)
POWER:
* Added optimized SCOPY/CCOPY kernels for POWER10
* Increased and unified the default size of the GEMM BUFFER
* Fixed building for POWER10 in DYNAMIC_ARCH mode
* POWER10 compatibility test now checks binutils version as well
* Cleaned up compiler warnings
x86_64:
* corrected compiler version checks for AVX2 compatibility
* added compiler option -mavx2 for building with flang
* fixed direct SGEMM pathway for small matrix sizes (broken by
the code refactoring in 0.3.11)
* fixed unhandled partial register clobbers in several kernels
for AXPY,DOT,GEMV_N and GEMV_T flagged by gcc10 tree-vectorizer
ARMV8:
* improved Apple Vortex support to include cross-compiling
====================================================================
Version 0.3.11
17-Oct-2020
common:
* API change:
the newly added BFLOAT16 functions were renamed to use the
letter "B" instead of "H" to avoid potential confusion with
the IEEE "half precision float" type, i.e. the 0.3.10
SHGEMM is now SBGEMM and the corresponding build option
was changed from "BUILD_HALF" to "BUILD_BFLOAT16".
* Reduced the default BLAS3_MEM_ALLOC_THRESHOLD (used as an upper
limit for placing temporary arrays on the stack) to be compatible
with a stack size of 1mb (as imposed by the JAVA runtime library)
* Added mixed-precision dot function SBDOT and utility functions
shstobf16, shdtobf16, sbf16tos and dbf16tod to convert between
single or double precision float arrays and bfloat16 arrays
* Fixed prototypes of LAPACK_?ggsvp and LAPACK_?ggsvd functions
in lapack.h
* Fixed underflow and rounding errors in LAPACK SLANV2 and DLANV2
(causing miscalculations in e.g. SHSEQR/DHSEQR, LAPACK issue #263)
* Fixed workspace calculation in LAPACK ?GELQ (LAPACK issue #415)
* Fixed several bugs in the LAPACK testsuite
* Improved performance of TRMM and TRSM for certain problem sizes
* Fixed infinite recursions and workspace miscalculations in ReLAPACK
* CMAKE builds no longer require pkg-config for creating the .pc file
* Makefile builds no longer misread NO_CBLAS=0 or NO_LAPACK=0 as
enabling these options
* Fixed detection of gfortran when invoked through an mpi wrapper
* Improve thread reinitialization performance with OpenMP after a fork
* Added support for building only the subset of the library required
for a particular precision by specifying BUILD_SINGLE, BUILD_DOUBLE
* Optional function name prefixes and suffixes are now correctly
reflected in the generated cblas.h
* Added CMAKE build support for the LAPACK and multithreading tests
POWER:
* Added optimized support for POWER10
* Added support for compiling for POWER8 in 32bit mode
* Added support for compilation with LLVM/clang
* Added support for compilation with NVIDIA/PGI compilers
* Fixed building on big-endian POWER8
* Fixed miscompilation of ZDOTC by gcc10
* Fixed alignment errors in the POWER8 SAXPY kernel
* Improved CPU detection on AIX
* Supported building with older compilers on POWER9
x86_64:
* Added support for Intel Cooperlake
* Added autodetection of AMD Renoir/Matisse/Zen3 cpus
* Added autodetection of Intel Comet Lake cpus
* Reimplemented ?sum, ?dot and daxpy using universal intrinsics
* Reset the fpu state before using the fpu on Windows as a workaround
for a problem introduced in Windows 10 build 19041 (a.k.a. SDK 2004)
* Fixed potentially undefined behaviour in the dot and gemv_t kernels
* Fixed a potential segmentation fault in DYNAMIC_ARCH builds
* Fixed building for ZEN with PGI/NVIDIA and AMD AOCC compilers
ARMV7:
* Fixed cpu detection on BSD-like systems
ARMV8:
* Added preliminary support for Apple Vortex cpus
* Added support for the Cavium ThunderX3T110 cpu
* Fixed cpu detection on BSD-like systems
* Fixed compilation in -std=C18 mode
IBM Z:
* Added support for compiling with the clang compiler
* Improved GEMM performance on Z14
2021-05-29 21:57:21 +02:00
|
|
|
MAKE_FLAGS+= LIBNAMESUFFIX=pthread
|
|
|
|
|
MAKE_FLAGS+= USE_OPENMP=0 USE_THREAD=1
|
2020-11-05 17:31:45 +01:00
|
|
|
BENCHMARK_ENV= OPENBLAS_NUM_THREADS=${BENCHMARK_MAXTHREADS}
|
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
2021-06-15 06:41:51 +02:00
|
|
|
.elif !empty(OPENBLAS_VARIANT:Mopenblas*_openmp)
|
math/openblas: update to version 0.3.15
This includes a rework of our patchery with the hope of upstreaming a good deal
of it.
These are the upstream changes since 0.3.10:
Version 0.3.15
2-May-2021
common:
- imported improvements and bugfixes from Reference-LAPACK 3.9.1
- imported LAPACKE interface fixes from Reference-LAPACK PRs 534 + 537
- fixed a problem in the cpu detection of 0.3.14 that prevented cross-compilation
- fixed a sequence problem in the generation of softlinks to the library in GMAKE
RISC V:
- fixed compilation on RISCV (missing entry in getarch)
- fixed a potential division by zero in CROTG and ZROTG
POWER:
- fixed LAPACK testsuite failures seen with the NVIDIA HPC compiler
- improved CGEMM, DGEMM and ZGEMM performance on POWER10
- added an optimized ZGEMV kernel for POWER10
- fixed a potential division by zero in CROTG and ZROTG
x86_64:
- added support for Intel Control-flow Enforcement Technology (CET)
- reverted the DOMATCOPY_RT code to the generic C version
- fixed a bug in the AVX512 SGEMM kernel introduced in 0.3.14
- fixed misapplication of -msse flag to non-SSE cpus in DYNAMIC_ARCH
- added support for compilation of the benchmarks on older OSX versions
- fix propagation of the NO_AVX512 option in CMAKE builds
- fix compilation of the AVX512 SGEMM kernel with clang-cl on Windows
- fixed compilation of the CTESTs with INTERFACE64=1 (random faults on OSX)
- corrected the Haswell DROT kernel to require AVX2/FMA3 rather than AVX512
ARM:
- fixed a potential division by zero in CROTG and ZROTG
- fixed a potential overflow in IMATCOPY/ZIMATCOPY and the CTESTs
ARM64:
- fixed spurious reads outside the array in the SGEMM tcopy macro
- fixed a potential division by zero in CROTG and ZROTG
- fixed a segmentation fault in DYNAMIC_ARCH builds (reappeared in 0.3.14)
MIPS
- fixed a potential division by zero in CROTG and ZROTG
- fixed a potential overflow in IMATCOPY/ZIMATCOPY and the CTESTs
MIPS64:
- fixed a potential division by zero in CROTG and ZROTG
SPARC:
- fixed a potential division by zero in CROTG and ZROTG
====================================================================
Version 0.3.14
17-Mar-2021
common:
* Fixed a race condition on thread shutdown in non-OpenMP builds
* Fixed custom BUFFERSIZE option getting ignored in gmake builds
* Fixed CMAKE compilation of the TRMM kernels for GENERIC platforms
* Added CBLAS interfaces for CROTG, ZROTG, CSROT and ZDROT
* Improved performance of OMATCOPY_RT across all platforms
* Changed perl scripts to use env instead of a hardcoded /usr/bin/perl
* Fixed potential misreading of the GCC compiler version in the build scripts
* Fixed convergence problems in LAPACK complex GGEV/GGES (Reference-LAPACK #477)
* Reduced the stacksize requirements for running the LAPACK testsuite (Reference-LAPACK #335)
RISCV:
* Fixed compilation on RISCV (missing entry in getarch)
POWER:
* Fixed compilation for DYNAMIC_ARCH with clang and with old gcc versions
* Added support for compilation on FreeBSD/ppc64le
* Added optimized POWER10 kernels for SSCAL, DSCAL, CSCAL, ZSCAL
* Added optimized POWER10 kernels for SROT, DROT, CDOT, SASUM, DASUM
* Improved SSWAP, DSWAP, CSWAP, ZSWAP performance on POWER10
* Improved SCOPY and CCOPY performance on POWER10
* Improved SGEMM and DGEMM performance on POWER10
* Added support for compilation with the NVIDIA HPC compiler
x86_64:
* Added an optimized bfloat16 GEMM kernel for Cooperlake
* Added CPUID autodetection for Intel Rocket Lake and Tiger Lake cpus
* Improved the performance of SASUM,DASUM,SROT,DROT on AMD Ryzen cpus
* Added support for compilation with the NAG Fortran compiler
* Fixed recognition of the AMD AOCC compiler
* Fixed compilation for DYNAMIC_ARCH with clang on Windows
* Added support for running the BLAS/CBLAS tests on Windows
* Fixed signatures of the tls callback functions for Windows x64
* Fixed various issues with fma intrinsics support handling
ARM:
* Added support for embedded Cortex M targets via a new option EMBEDDED
ARMV8:
* Fixed the THUNDERX2T99 and NEOVERSEN1 DNRM2/ZNRM2 kernels for inputs with Inf
* Added support for the DYNAMIC_LIST option
* Added support for compilation with the NVIDIA HPC compiler
* Added support for compiling with the NAG Fortran compiler
====================================================================
Version 0.3.13
12-Dec-2020
common:
* Added a generic bfloat16 SBGEMV kernel
* Fixed a potentially severe memory leak after fork in OpenMP builds
that was introduced in 0.3.12
* Added detection of the Fujitsu Fortran compiler
* Added detection of the (e)gfortran compiler on OpenBSD
* Added support for overriding the default name of the library independently
from symbol suffixing in the gmake builds (already supported in cmake)
RISCV:
* Added a RISC V port optimized for C910V
POWER:
* Added optimized POWER10 kernels for SAXPY, CAXPY, SDOT, DDOT and DGEMV_N
* Improved DGEMM performance on POWER10
* Improved STRSM and DTRSM performance on POWER9 and POWER10
* Fixed segmemtation faults in DYNAMIC_ARCH builds
* Fixed compilation with the PGI compiler
x86:
* Fixed compilation of kernels that require SSE2 intrinsics since 0.3.12
x86_64:
* Added an optimized bfloat16 SBGEMV kernel for SkylakeX and Cooperlake
* Improved the performance of SASUM and DASUM kernels through parallelization
* Improved the performance of SROT and DROT kernels
* Improved the performance of multithreaded xSYRK
* Fixed OpenMP builds that use the LLVM Clang compiler together with GNU gfortran
(where linking of both the LLVM libomp and GNU libgomp could lead to lockups or
wrong results)
* Fixed miscompilations by old gcc 4.6
* Fixed misdetection of AVX2 capability in some Sandybridge cpus
* Fixed lockups in builds combining DYNAMIC_ARCH with TARGET=GENERIC on OpenBSD
ARM64:
* Fixed segmemtation faults in DYNAMIC_ARCH builds
MIPS:
* Improved kernels for Loongson 3R3 ("3A") and 3R4 ("3B") models, including MSA
* Fixed bugs in the MSA kernels for CGEMM, CTRMM, CGEMV and ZGEMV
* Added handling of zero increments in the MSA kernels for SSWAP and DSWAP
* Added DYNAMIC_ARCH support for MIPS64 (currently Loongson3R3/3R4 only)
SPARC:
* Fixed building 32 and 64 bit SPARC kernels with the SolarisStudio compilers
====================================================================
Version 0.3.12
24-Oct-2020
common:
* Fixed missing BLAS/LAPACK functions (inadvertently dropped during
the build system restructuring)
* Fixed argument conversion macro in LAPACKE_zgesvdq (LAPACK #458)
POWER:
* Added optimized SCOPY/CCOPY kernels for POWER10
* Increased and unified the default size of the GEMM BUFFER
* Fixed building for POWER10 in DYNAMIC_ARCH mode
* POWER10 compatibility test now checks binutils version as well
* Cleaned up compiler warnings
x86_64:
* corrected compiler version checks for AVX2 compatibility
* added compiler option -mavx2 for building with flang
* fixed direct SGEMM pathway for small matrix sizes (broken by
the code refactoring in 0.3.11)
* fixed unhandled partial register clobbers in several kernels
for AXPY,DOT,GEMV_N and GEMV_T flagged by gcc10 tree-vectorizer
ARMV8:
* improved Apple Vortex support to include cross-compiling
====================================================================
Version 0.3.11
17-Oct-2020
common:
* API change:
the newly added BFLOAT16 functions were renamed to use the
letter "B" instead of "H" to avoid potential confusion with
the IEEE "half precision float" type, i.e. the 0.3.10
SHGEMM is now SBGEMM and the corresponding build option
was changed from "BUILD_HALF" to "BUILD_BFLOAT16".
* Reduced the default BLAS3_MEM_ALLOC_THRESHOLD (used as an upper
limit for placing temporary arrays on the stack) to be compatible
with a stack size of 1mb (as imposed by the JAVA runtime library)
* Added mixed-precision dot function SBDOT and utility functions
shstobf16, shdtobf16, sbf16tos and dbf16tod to convert between
single or double precision float arrays and bfloat16 arrays
* Fixed prototypes of LAPACK_?ggsvp and LAPACK_?ggsvd functions
in lapack.h
* Fixed underflow and rounding errors in LAPACK SLANV2 and DLANV2
(causing miscalculations in e.g. SHSEQR/DHSEQR, LAPACK issue #263)
* Fixed workspace calculation in LAPACK ?GELQ (LAPACK issue #415)
* Fixed several bugs in the LAPACK testsuite
* Improved performance of TRMM and TRSM for certain problem sizes
* Fixed infinite recursions and workspace miscalculations in ReLAPACK
* CMAKE builds no longer require pkg-config for creating the .pc file
* Makefile builds no longer misread NO_CBLAS=0 or NO_LAPACK=0 as
enabling these options
* Fixed detection of gfortran when invoked through an mpi wrapper
* Improve thread reinitialization performance with OpenMP after a fork
* Added support for building only the subset of the library required
for a particular precision by specifying BUILD_SINGLE, BUILD_DOUBLE
* Optional function name prefixes and suffixes are now correctly
reflected in the generated cblas.h
* Added CMAKE build support for the LAPACK and multithreading tests
POWER:
* Added optimized support for POWER10
* Added support for compiling for POWER8 in 32bit mode
* Added support for compilation with LLVM/clang
* Added support for compilation with NVIDIA/PGI compilers
* Fixed building on big-endian POWER8
* Fixed miscompilation of ZDOTC by gcc10
* Fixed alignment errors in the POWER8 SAXPY kernel
* Improved CPU detection on AIX
* Supported building with older compilers on POWER9
x86_64:
* Added support for Intel Cooperlake
* Added autodetection of AMD Renoir/Matisse/Zen3 cpus
* Added autodetection of Intel Comet Lake cpus
* Reimplemented ?sum, ?dot and daxpy using universal intrinsics
* Reset the fpu state before using the fpu on Windows as a workaround
for a problem introduced in Windows 10 build 19041 (a.k.a. SDK 2004)
* Fixed potentially undefined behaviour in the dot and gemv_t kernels
* Fixed a potential segmentation fault in DYNAMIC_ARCH builds
* Fixed building for ZEN with PGI/NVIDIA and AMD AOCC compilers
ARMV7:
* Fixed cpu detection on BSD-like systems
ARMV8:
* Added preliminary support for Apple Vortex cpus
* Added support for the Cavium ThunderX3T110 cpu
* Fixed cpu detection on BSD-like systems
* Fixed compilation in -std=C18 mode
IBM Z:
* Added support for compiling with the clang compiler
* Improved GEMM performance on Z14
2021-05-29 21:57:21 +02:00
|
|
|
MAKE_FLAGS+= LIBNAMESUFFIX=openmp
|
|
|
|
|
MAKE_FLAGS+= USE_OPENMP=1 NO_AFFINITY=1
|
2020-11-05 17:31:45 +01:00
|
|
|
BENCHMARK_ENV= OMP_NUM_THREADS=${BENCHMARK_MAXTHREADS}
|
|
|
|
|
.endif
|
|
|
|
|
|
mk/blas.bl3, Netlib and OpenBLAS packages, NumPy: C fixup and 64 bits
This delivers 64 bit index BLAS libraries alongside 32 bit ones. This is often
called ILP64 in the BLAS world, as opposed to LP64 where integers are 32 bit
due to the Fortran default integer type, not to be confused with the basic
system ABI used by C. For really large vectors on modern machines, you want
an 'ILP64' BLAS and layers on top of it.
In preparation of better support for vendor BLAS libraries, I had to realize
that you better use the C interfaces supplied by them, not the netlib one
strapped on. A simple reason of practicability: The vendor blas libraries,
just like openblas, like to ship all symbols in one library, so you get them
whether you want it or not. Also implementations may skip Fortran and implement
the underlying functionality directly in C anyway, so one might skip a
layer of indirection. Future will tell if other layers will follow. We still
have the framework of individual layers from Netlib to combine with certain
implementations that miss them (Accelerate framework comes to mind, which
needs further work).
The framework of netlib reference packages for the separate libraries
is instructive and helps keeping things small when you not need all of them.
The installation location of the headers is now in a subdirectory to be able
to have 32 and 64 bit variants independently. The 32 bit ones are linked to
${PREFIX}/include to keep the old picture. We could be brave and remove
those, but there is some value in a build just trying -lcblas and
inclusion of <cblas.h> to be happy.
There is one blas.buildlink3.mk that is supposed to be used only once and
so avoids a combination of conflicting libraries (as the 64 bit index symbols
have the same names as the 32 bit ones).
Basic usage for getting LAPACK+BLAS is still the same as before. You get
CBLAS and LAPACKE by setting BLAS_C_INTERFACE=yes in the package. The 64 bit
indices are selected via BLAS_INDEX64=yes.
Due to the special nature of the Accelerate framework, a package has to
explicitly indicate support for it and it will also not appear on the
list of implementations by default. The reason is that it does provide
mainly CBLAS and CLAPACK (another version of C interface to LAPACK, f2c-based)
and BLAS/LAPACK with f2c/g77 calling conventions. A default build with
gfortran would not like that
This commit also fixes up math/py-numpy and math/py-numpy16 to follow the
new scheme, as that are the only packages directly affected by the change
in CBLAS providership.
2021-06-15 06:41:51 +02:00
|
|
|
.if !empty(OPENBLAS_VARIANT:M*64*)
|
|
|
|
|
MAKE_FLAGS+= INTERFACE64=1 LIBSONAMEBASE=openblas64
|
|
|
|
|
.endif
|
|
|
|
|
|
2020-11-05 17:31:45 +01:00
|
|
|
SUBST_CLASSES+= threads
|
|
|
|
|
SUBST_STAGE.threads= pre-build
|
|
|
|
|
SUBST_SED.threads+= -e "s+OPENBLAS_NUM_THREADS+OMP_NUM_THREADS+g"
|
|
|
|
|
SUBST_FILES.threads+= test/Makefile
|
|
|
|
|
SUBST_FILES.threads+= ctest/Makefile
|
|
|
|
|
|
|
|
|
|
PLIST_SRC= ${.CURDIR}/../../math/openblas/PLIST
|
|
|
|
|
PLIST_SUBST+= OPENBLAS_VARIANT=${OPENBLAS_VARIANT}
|
|
|
|
|
|
|
|
|
|
post-extract:
|
math/openblas: update to version 0.3.15
This includes a rework of our patchery with the hope of upstreaming a good deal
of it.
These are the upstream changes since 0.3.10:
Version 0.3.15
2-May-2021
common:
- imported improvements and bugfixes from Reference-LAPACK 3.9.1
- imported LAPACKE interface fixes from Reference-LAPACK PRs 534 + 537
- fixed a problem in the cpu detection of 0.3.14 that prevented cross-compilation
- fixed a sequence problem in the generation of softlinks to the library in GMAKE
RISC V:
- fixed compilation on RISCV (missing entry in getarch)
- fixed a potential division by zero in CROTG and ZROTG
POWER:
- fixed LAPACK testsuite failures seen with the NVIDIA HPC compiler
- improved CGEMM, DGEMM and ZGEMM performance on POWER10
- added an optimized ZGEMV kernel for POWER10
- fixed a potential division by zero in CROTG and ZROTG
x86_64:
- added support for Intel Control-flow Enforcement Technology (CET)
- reverted the DOMATCOPY_RT code to the generic C version
- fixed a bug in the AVX512 SGEMM kernel introduced in 0.3.14
- fixed misapplication of -msse flag to non-SSE cpus in DYNAMIC_ARCH
- added support for compilation of the benchmarks on older OSX versions
- fix propagation of the NO_AVX512 option in CMAKE builds
- fix compilation of the AVX512 SGEMM kernel with clang-cl on Windows
- fixed compilation of the CTESTs with INTERFACE64=1 (random faults on OSX)
- corrected the Haswell DROT kernel to require AVX2/FMA3 rather than AVX512
ARM:
- fixed a potential division by zero in CROTG and ZROTG
- fixed a potential overflow in IMATCOPY/ZIMATCOPY and the CTESTs
ARM64:
- fixed spurious reads outside the array in the SGEMM tcopy macro
- fixed a potential division by zero in CROTG and ZROTG
- fixed a segmentation fault in DYNAMIC_ARCH builds (reappeared in 0.3.14)
MIPS
- fixed a potential division by zero in CROTG and ZROTG
- fixed a potential overflow in IMATCOPY/ZIMATCOPY and the CTESTs
MIPS64:
- fixed a potential division by zero in CROTG and ZROTG
SPARC:
- fixed a potential division by zero in CROTG and ZROTG
====================================================================
Version 0.3.14
17-Mar-2021
common:
* Fixed a race condition on thread shutdown in non-OpenMP builds
* Fixed custom BUFFERSIZE option getting ignored in gmake builds
* Fixed CMAKE compilation of the TRMM kernels for GENERIC platforms
* Added CBLAS interfaces for CROTG, ZROTG, CSROT and ZDROT
* Improved performance of OMATCOPY_RT across all platforms
* Changed perl scripts to use env instead of a hardcoded /usr/bin/perl
* Fixed potential misreading of the GCC compiler version in the build scripts
* Fixed convergence problems in LAPACK complex GGEV/GGES (Reference-LAPACK #477)
* Reduced the stacksize requirements for running the LAPACK testsuite (Reference-LAPACK #335)
RISCV:
* Fixed compilation on RISCV (missing entry in getarch)
POWER:
* Fixed compilation for DYNAMIC_ARCH with clang and with old gcc versions
* Added support for compilation on FreeBSD/ppc64le
* Added optimized POWER10 kernels for SSCAL, DSCAL, CSCAL, ZSCAL
* Added optimized POWER10 kernels for SROT, DROT, CDOT, SASUM, DASUM
* Improved SSWAP, DSWAP, CSWAP, ZSWAP performance on POWER10
* Improved SCOPY and CCOPY performance on POWER10
* Improved SGEMM and DGEMM performance on POWER10
* Added support for compilation with the NVIDIA HPC compiler
x86_64:
* Added an optimized bfloat16 GEMM kernel for Cooperlake
* Added CPUID autodetection for Intel Rocket Lake and Tiger Lake cpus
* Improved the performance of SASUM,DASUM,SROT,DROT on AMD Ryzen cpus
* Added support for compilation with the NAG Fortran compiler
* Fixed recognition of the AMD AOCC compiler
* Fixed compilation for DYNAMIC_ARCH with clang on Windows
* Added support for running the BLAS/CBLAS tests on Windows
* Fixed signatures of the tls callback functions for Windows x64
* Fixed various issues with fma intrinsics support handling
ARM:
* Added support for embedded Cortex M targets via a new option EMBEDDED
ARMV8:
* Fixed the THUNDERX2T99 and NEOVERSEN1 DNRM2/ZNRM2 kernels for inputs with Inf
* Added support for the DYNAMIC_LIST option
* Added support for compilation with the NVIDIA HPC compiler
* Added support for compiling with the NAG Fortran compiler
====================================================================
Version 0.3.13
12-Dec-2020
common:
* Added a generic bfloat16 SBGEMV kernel
* Fixed a potentially severe memory leak after fork in OpenMP builds
that was introduced in 0.3.12
* Added detection of the Fujitsu Fortran compiler
* Added detection of the (e)gfortran compiler on OpenBSD
* Added support for overriding the default name of the library independently
from symbol suffixing in the gmake builds (already supported in cmake)
RISCV:
* Added a RISC V port optimized for C910V
POWER:
* Added optimized POWER10 kernels for SAXPY, CAXPY, SDOT, DDOT and DGEMV_N
* Improved DGEMM performance on POWER10
* Improved STRSM and DTRSM performance on POWER9 and POWER10
* Fixed segmemtation faults in DYNAMIC_ARCH builds
* Fixed compilation with the PGI compiler
x86:
* Fixed compilation of kernels that require SSE2 intrinsics since 0.3.12
x86_64:
* Added an optimized bfloat16 SBGEMV kernel for SkylakeX and Cooperlake
* Improved the performance of SASUM and DASUM kernels through parallelization
* Improved the performance of SROT and DROT kernels
* Improved the performance of multithreaded xSYRK
* Fixed OpenMP builds that use the LLVM Clang compiler together with GNU gfortran
(where linking of both the LLVM libomp and GNU libgomp could lead to lockups or
wrong results)
* Fixed miscompilations by old gcc 4.6
* Fixed misdetection of AVX2 capability in some Sandybridge cpus
* Fixed lockups in builds combining DYNAMIC_ARCH with TARGET=GENERIC on OpenBSD
ARM64:
* Fixed segmemtation faults in DYNAMIC_ARCH builds
MIPS:
* Improved kernels for Loongson 3R3 ("3A") and 3R4 ("3B") models, including MSA
* Fixed bugs in the MSA kernels for CGEMM, CTRMM, CGEMV and ZGEMV
* Added handling of zero increments in the MSA kernels for SSWAP and DSWAP
* Added DYNAMIC_ARCH support for MIPS64 (currently Loongson3R3/3R4 only)
SPARC:
* Fixed building 32 and 64 bit SPARC kernels with the SolarisStudio compilers
====================================================================
Version 0.3.12
24-Oct-2020
common:
* Fixed missing BLAS/LAPACK functions (inadvertently dropped during
the build system restructuring)
* Fixed argument conversion macro in LAPACKE_zgesvdq (LAPACK #458)
POWER:
* Added optimized SCOPY/CCOPY kernels for POWER10
* Increased and unified the default size of the GEMM BUFFER
* Fixed building for POWER10 in DYNAMIC_ARCH mode
* POWER10 compatibility test now checks binutils version as well
* Cleaned up compiler warnings
x86_64:
* corrected compiler version checks for AVX2 compatibility
* added compiler option -mavx2 for building with flang
* fixed direct SGEMM pathway for small matrix sizes (broken by
the code refactoring in 0.3.11)
* fixed unhandled partial register clobbers in several kernels
for AXPY,DOT,GEMV_N and GEMV_T flagged by gcc10 tree-vectorizer
ARMV8:
* improved Apple Vortex support to include cross-compiling
====================================================================
Version 0.3.11
17-Oct-2020
common:
* API change:
the newly added BFLOAT16 functions were renamed to use the
letter "B" instead of "H" to avoid potential confusion with
the IEEE "half precision float" type, i.e. the 0.3.10
SHGEMM is now SBGEMM and the corresponding build option
was changed from "BUILD_HALF" to "BUILD_BFLOAT16".
* Reduced the default BLAS3_MEM_ALLOC_THRESHOLD (used as an upper
limit for placing temporary arrays on the stack) to be compatible
with a stack size of 1mb (as imposed by the JAVA runtime library)
* Added mixed-precision dot function SBDOT and utility functions
shstobf16, shdtobf16, sbf16tos and dbf16tod to convert between
single or double precision float arrays and bfloat16 arrays
* Fixed prototypes of LAPACK_?ggsvp and LAPACK_?ggsvd functions
in lapack.h
* Fixed underflow and rounding errors in LAPACK SLANV2 and DLANV2
(causing miscalculations in e.g. SHSEQR/DHSEQR, LAPACK issue #263)
* Fixed workspace calculation in LAPACK ?GELQ (LAPACK issue #415)
* Fixed several bugs in the LAPACK testsuite
* Improved performance of TRMM and TRSM for certain problem sizes
* Fixed infinite recursions and workspace miscalculations in ReLAPACK
* CMAKE builds no longer require pkg-config for creating the .pc file
* Makefile builds no longer misread NO_CBLAS=0 or NO_LAPACK=0 as
enabling these options
* Fixed detection of gfortran when invoked through an mpi wrapper
* Improve thread reinitialization performance with OpenMP after a fork
* Added support for building only the subset of the library required
for a particular precision by specifying BUILD_SINGLE, BUILD_DOUBLE
* Optional function name prefixes and suffixes are now correctly
reflected in the generated cblas.h
* Added CMAKE build support for the LAPACK and multithreading tests
POWER:
* Added optimized support for POWER10
* Added support for compiling for POWER8 in 32bit mode
* Added support for compilation with LLVM/clang
* Added support for compilation with NVIDIA/PGI compilers
* Fixed building on big-endian POWER8
* Fixed miscompilation of ZDOTC by gcc10
* Fixed alignment errors in the POWER8 SAXPY kernel
* Improved CPU detection on AIX
* Supported building with older compilers on POWER9
x86_64:
* Added support for Intel Cooperlake
* Added autodetection of AMD Renoir/Matisse/Zen3 cpus
* Added autodetection of Intel Comet Lake cpus
* Reimplemented ?sum, ?dot and daxpy using universal intrinsics
* Reset the fpu state before using the fpu on Windows as a workaround
for a problem introduced in Windows 10 build 19041 (a.k.a. SDK 2004)
* Fixed potentially undefined behaviour in the dot and gemv_t kernels
* Fixed a potential segmentation fault in DYNAMIC_ARCH builds
* Fixed building for ZEN with PGI/NVIDIA and AMD AOCC compilers
ARMV7:
* Fixed cpu detection on BSD-like systems
ARMV8:
* Added preliminary support for Apple Vortex cpus
* Added support for the Cavium ThunderX3T110 cpu
* Fixed cpu detection on BSD-like systems
* Fixed compilation in -std=C18 mode
IBM Z:
* Added support for compiling with the clang compiler
* Improved GEMM performance on Z14
2021-05-29 21:57:21 +02:00
|
|
|
rm ${WRKSRC}/relapack/src/lapack_wrappers.c.orig
|
2020-11-05 17:31:45 +01:00
|
|
|
(cd ${DISTDIR}/${DIST_SUBDIR} && \
|
|
|
|
|
${CP} ${LARGE_FILE} ${TIMING_FILE} ${WRKSRC})
|
|
|
|
|
|
|
|
|
|
# This builds some benchmark programs you can call from ${WRKSRC} afterwards.
|
|
|
|
|
.PHONY: benchmark
|
|
|
|
|
benchmark: build
|
|
|
|
|
(cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${BENCHMARK_ENV} \
|
|
|
|
|
${MAKE_PROGRAM} ${MAKE_FLAGS} hpl)
|
|
|
|
|
(cd ${WRKSRC}/benchmark && ${SETENV} ${MAKE_ENV} \
|
|
|
|
|
${BENCHMARK_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS})
|
|
|
|
|
|
|
|
|
|
.include "../../math/openblas/version.mk"
|
|
|
|
|
|
|
|
|
|
.include "options.mk"
|
