ILP64 name-mangling

Open discussion for MAGMA library (Matrix Algebra on GPU and Multicore Architectures)
Post Reply
staticfloat
Posts: 2
Joined: Fri Aug 09, 2019 3:33 pm

ILP64 name-mangling

Post by staticfloat » Fri Aug 09, 2019 3:47 pm

In the Julia language world, we tend to build Julia against an ILP64 BLAS (OpenBLAS, in the default case), but occasionally users link against dynamic libraries that expect a non-ILP64 BLAS. To avoid potentially fatal symbol name clashes, we mangle the name of all ILP64 BLAS operations (e.g. `dgemv_` becomes `dgemv64_`). What is the proper way to convince MAGMA to mangle its expected BLAS symbol names appropriately so that it can link against these ILP64 symbols? I've tried editing `include/magma_mangling.h` to have preprocessor defines such as `#define FORTRAN_NAME(lcname, UCNAME) lcname##64_`, but that doesn't seem to work. I'm compiling using CMake. I have also tried editing `include/magma_mangling_cmake.h`, but I believe that file is autogenerated (and gets overwritten) and I'm unsure where it is generated from.

mgates3
Posts: 893
Joined: Fri Jan 06, 2012 2:13 pm

Re: ILP64 name-mangling

Post by mgates3 » Fri Aug 09, 2019 4:55 pm

If you compiled without CMake, then editing magma_mangling.h as you describe should work. But as you noticed, CMake #defines its own mangling macro, called MAGMA_GLOBAL, in the file magma_mangling_cmake.h.

The quickest hack to do would be comment out magma_mangling_cmake (or #undef MAGMA_GLOBAL), and then edit FORTRAN_NAME macro as you described. Something like this, in magma_mangling.h:

Code: Select all

// #include "magma_mangling_cmake.h"  // Comment out CMake's mangling macro,
#undef MAGMA_GLOBAL                   // or undef it.

// Define ADD_, NOCHANGE, or UPCASE as appropriate.
// Normally with Makefile this would be defined in CXXFLAGS.
#define ADD_

#ifndef MAGMA_FORTRAN_NAME
    #if defined(MAGMA_GLOBAL)
        #define FORTRAN_NAME(lcname, UCNAME)  MAGMA_GLOBAL( lcname, UCNAME )
    #elif defined(ADD_)
        #define FORTRAN_NAME(lcname, UCNAME)  lcname##64_  // Add "64" as you suggested
...
-mark

staticfloat
Posts: 2
Joined: Fri Aug 09, 2019 3:33 pm

Re: ILP64 name-mangling

Post by staticfloat » Fri Aug 09, 2019 8:43 pm

Thanks, I'll try that. I also haven't found any guidance on how to enable ILP64 with CMake; I'm exporting `CFLAGS=-DMAGMA_ILP64` before running `cmake`, is that the recommended way?

mgates3
Posts: 893
Joined: Fri Jan 06, 2012 2:13 pm

Re: ILP64 name-mangling

Post by mgates3 » Sun Aug 11, 2019 9:13 am

That should work. Ideally, CMake would detect 64-bit BLAS, which we do in some other projects (BLAS++) but not yet in MAGMA.
-mark

mgates3
Posts: 893
Joined: Fri Jan 06, 2012 2:13 pm

Re: ILP64 name-mangling

Post by mgates3 » Mon Aug 12, 2019 12:26 pm

On second glance, it doesn't appear that CFLAGS is propagated to CXXFLAGS by CMake, and it won't propagate to Fortran or NVCC for CUDA. Even worse, it doesn't seem that CMake picks up NVCCFLAGS from the environment, so there doesn't appear to be a way to override or append to it, without editing CMakeLists.txt.

So currently, you may need to edit CMakeLists.txt to add an option something like this:

Code: Select all

# ----------------------------------------
# Ideally, CMake would auto-detect ILP64 in the BLAS/LAPACK library.
# As a work-around, make it an option.
option( ILP64 "BLAS and LAPACK are ILP64 (64-bit int) instead of usual LP64 (32-bit int)." off )
if (ILP64)
    set( CMAKE_C_FLAGS   "${CMAKE_C_FLAGS} -DMAGMA_ILP64" )
    set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DMAGMA_ILP64" )
    set( CUDA_NVCC_FLAGS "${CUDA_NVCC_FLAGS};-DMAGMA_ILP64" )  # semicolon
    set( CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -fdefault-integer-8" )
endif()
Sorry, ILP64 isn't an option we've tried doing through CMake before, and as usual, CMake makes customization difficult.

-mark

Post Reply