LoongArch64: Rename core

[XiWeiGu]

The current naming convention is not a very formal expression. After the revision, both the CPU name and Core name will be represented by the LA64 microarchitecture.
The definition of CPU name is as follows, which includes the currently known LA64 microarchitectures, representing the microarchitecture of the current host:

static char *cpuname[] = {
  "LA64_GENERIC",
  "LA264", /* Loongarch 64-bit, 2-issue, similar to 2K1000LA */
  "LA364", /* Loongarch 64-bit, 3-issue, similar to 2K2000 */
  "LA464", /* Loongarch 64-bit, 4-issue, similar to 3A5000, 3C5000L, 3C5000, and 3D5000 */
  "LA664"  /* Loongarch 64-bit, 6-issue, similar to 3A6000, 3C6000, and 3D6000 */
};

The definition of Core name is as follows, representing the LA64 microarchitecture related to the instruction set, which reflects the selected optimization type:

static char *corename[] = {
  "LA64_GENERIC", /* Represents optimization using scalar instructions */
  "LA264", /* Represents optimization using LSX instructions */
  "LA464", /* Represents optimization using LASX instructions */
};

Among these, LA64_GENERIC is related to scalar optimizations; LA264 corresponds to LSX instruction optimizations; and LA464 corresponds to LASX instruction optimizations.

The core is selected based on the CPU name and the instruction set supported by the system.

For LA364, although it supports LSX instructions, it lacks additional extensions. Currently, there is no need for further optimization of the existing LSX instructions. Therefore, no new core is required, and the LA264 optimization approach can be reused. Similarly, this principle applies to LA664. This approach has the advantage of reducing compilation time and code size when DYNAMIC_ARCH=1 is enabled.

Taking 3A6000 as an example, its CPU name is LA664, while its Core name is LA464 because it shares the same optimization approach as LA464.

The addition of a new CPU name is based on the emergence of new LA64 microarchitectures, while a new Core name is added only when the new LA64 microarchitecture introduces a new instruction set or other significant performance optimizations. This approach helps prevent code bloat while ensuring streamlined and efficient optimization code.

[XiWeiGu]

@yinshiyou @martin-frbg @azuresky01 @Pengzhou0810 Could you help me review the code to see if there are any missing parts? Thanks!

[martin-frbg]

I must say I am not particularly happy with renaming TARGET entries that have been in use for quite a while. Can we at least keep the present names as aliases so that users and distributors will not have to change their build scripts (and whatever local documentation there may be out there) ?

[XiWeiGu]

Okay, I understand your concerns. I have retained the existing TARGET, and users can still specify it during compilation and runtime (it will be internally assigned to the ‘new’ TARGET)

[azuresky01]

@XiWeiGu

Hello, I just tried to build OpenBLAS from the files in your la64_core_rename branch. Unfortunately both gmake and cmake failed. See below.

The system is Debian sid with kernel 6.10.2, gcc 14.2.0, cmake 3.30.3, and CPU is Loongson 3A6000.

gmake command: make, output:

/usr/bin/ld: /tmp/ccLfTq5h.o: in function `.L9':
getarch.c:(.text+0x104): undefined reference to `pow'
/usr/bin/ld: getarch.c:(.text+0x158): undefined reference to `pow'
/usr/bin/ld: /tmp/ccLfTq5h.o: in function `.L8':
getarch.c:(.text+0x1f0): undefined reference to `pow'
/usr/bin/ld: getarch.c:(.text+0x244): undefined reference to `pow'
/usr/bin/ld: /tmp/ccLfTq5h.o: in function `.L7':
getarch.c:(.text+0x2ec): undefined reference to `pow'
/usr/bin/ld: /tmp/ccLfTq5h.o:getarch.c:(.text+0x340): more undefined references to `pow' follow
collect2: error: ld returned 1 exit status
make: *** [Makefile.prebuild:100: getarch] Error 1
Makefile.system:1585: Makefile.: No such file or directory
make: *** No rule to make target 'Makefile.'.  Stop.

cmake command: cmake -B build, output:

CMake Deprecation Warning at CMakeLists.txt:5 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- The C compiler identification is GNU 14.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
CMake Warning at CMakeLists.txt:103 (message):
  CMake support is experimental.  It does not yet support all build options
  and may not produce the same Makefiles that OpenBLAS ships with.


CMake Warning (dev) at cmake/system_check.cmake:13 (if):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "LINUX" will no longer be dereferenced when the
  policy is set to NEW.  Since the policy is not set the OLD behavior will be
  used.
Call Stack (most recent call first):
  cmake/system.cmake:8 (include)
  CMakeLists.txt:106 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Looking for stdatomic.h
-- Looking for stdatomic.h - found
-- GEMM multithread threshold set to 4.
-- Multi-threading enabled with 8 threads.
-- Looking for a Fortran compiler
-- Looking for a Fortran compiler - /usr/bin/f95
-- The Fortran compiler identification is GNU 14.2.0
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /usr/bin/f95 - skipped
CMake Error at cmake/prebuild.cmake:1421 (MESSAGE):
  Compiling getarch failed Change Dir:
  '/home/loongson/test/build_OpenBLAS/build/getarch_build/CMakeFiles/CMakeTmp'




  Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /usr/bin/gmake -f
  Makefile cmTC_c77b0/fast

  /usr/bin/gmake -f CMakeFiles/cmTC_c77b0.dir/build.make
  CMakeFiles/cmTC_c77b0.dir/build

  gmake[1]: Entering directory
  '/home/loongson/test/build_OpenBLAS/build/getarch_build/CMakeFiles/CMakeTmp'


  Building C object CMakeFiles/cmTC_c77b0.dir/getarch.c.o

  /usr/bin/cc -DGEMM_MULTITHREAD_THRESHOLD=4 -DNO_PARALLEL_MAKE=0
  -I"/home/loongson/test/build_OpenBLAS/build/getarch_build"
  -I"/home/loongson/test/build_OpenBLAS"
  -I"/home/loongson/test/build_OpenBLAS/build" -o
  CMakeFiles/cmTC_c77b0.dir/getarch.c.o -c
  /home/loongson/test/build_OpenBLAS/getarch.c

  Building ASM object CMakeFiles/cmTC_c77b0.dir/cpuid.S.o

  /usr/bin/cc -DGEMM_MULTITHREAD_THRESHOLD=4 -DNO_PARALLEL_MAKE=0
  -I"/home/loongson/test/build_OpenBLAS/build/getarch_build"
  -I"/home/loongson/test/build_OpenBLAS"
  -I"/home/loongson/test/build_OpenBLAS/build" -o
  CMakeFiles/cmTC_c77b0.dir/cpuid.S.o -c
  /home/loongson/test/build_OpenBLAS/cpuid.S

  Linking C executable cmTC_c77b0

  /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_c77b0.dir/link.txt
  --verbose=1

  /usr/bin/cc -rdynamic CMakeFiles/cmTC_c77b0.dir/getarch.c.o
  CMakeFiles/cmTC_c77b0.dir/cpuid.S.o -o cmTC_c77b0

  /usr/bin/ld: CMakeFiles/cmTC_c77b0.dir/getarch.c.o: in function `.L9':

  getarch.c:(.text+0x104): undefined reference to `pow'

  /usr/bin/ld: getarch.c:(.text+0x158): undefined reference to `pow'

  /usr/bin/ld: CMakeFiles/cmTC_c77b0.dir/getarch.c.o: in function `.L8':

  getarch.c:(.text+0x1f0): undefined reference to `pow'

  /usr/bin/ld: getarch.c:(.text+0x244): undefined reference to `pow'

  /usr/bin/ld: CMakeFiles/cmTC_c77b0.dir/getarch.c.o: in function `.L7':

  getarch.c:(.text+0x2ec): undefined reference to `pow'

  /usr/bin/ld: CMakeFiles/cmTC_c77b0.dir/getarch.c.o:getarch.c:(.text+0x340):
  more undefined references to `pow' follow

  collect2: error: ld returned 1 exit status

  gmake[1]: *** [CMakeFiles/cmTC_c77b0.dir/build.make:114: cmTC_c77b0] Error
  1

  gmake[1]: Leaving directory
  '/home/loongson/test/build_OpenBLAS/build/getarch_build/CMakeFiles/CMakeTmp'


  gmake: *** [Makefile:127: cmTC_c77b0/fast] Error 2



Call Stack (most recent call first):
  cmake/system.cmake:169 (include)
  CMakeLists.txt:106 (include)


-- Configuring incomplete, errors occurred!

[XiWeiGu]

@azuresky01 Thank you very much for your testing.
From the error message, it seems that the ‘-lm’ option was not added to the compilation of getarch.c in the gmake and cmake builds (the pow function is used in cpuid_loongarch.c to calculate the cache size). I will fix it promptly next week.

[martin-frbg]

I wonder if it would be possible to use shifs instead, if all you need the pow (and libm) for is powers of two ?

[XiWeiGu]

@martin-frbg @azuresky01 Thank you for your suggestions, the update has been submitted.

[azuresky01]

@martin-frbg @azuresky01 Thank you for your suggestions, the update has been submitted.

I can confirm that after the update both gmake and cmake compilations are OK. The compiler is gcc/gfortran 14.2.0 on Debian sid.