Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write new ETI system compatible with Makefile-based build system #21

Closed
mhoemmen opened this issue Mar 28, 2017 · 2 comments
Closed

Write new ETI system compatible with Makefile-based build system #21

mhoemmen opened this issue Mar 28, 2017 · 2 comments
Assignees

Comments

@mhoemmen
Copy link
Contributor

mhoemmen commented Mar 28, 2017

Story: #1

ETI stands for "explicit template instantiation." We weren't and aren't strictly using ETI. Instead, we "prebuild" kernels for a small set of template parameter combinations, determined at configure time. We also (will) have an option to disable use of template parameter combinations outside that set. This will help both developers and users reduce build times and library sizes, by determining whether they are unexpectedly using combinations outside the set of prebuilt combinations.

We used to use macros to generate prebuilt combinations. We're switching to the C++11 extern template approach, which obviates the need for definition macros that duplicate code in the templated definitions.

The default solution needs to respect
trilinos/Trilinos#362
and thus, it needs to respect the following CMake variables:

  • Trilinos_ENABLE_FLOAT
  • Trilinos_ENABLE_COMPLEX_DOUBLE
  • Trilinos_ENABLE_COMPLEX_FLOAT
  • (in theory, also, Trilinos_ENABLE_COMPLEX, though no Trilinos package currently uses that)

New macro names:

  • KOKKOSKERNELS_INST_SCALAR_${SCALAR}
  • KOKKOSKERNELS_INST_LAYOUT_${LAYOUT}
  • KOKKOSKERNELS_INST_EXECSPACE_${EXECSPACE}
  • KOKKOSKERNELS_INST_MEMSPACE_${MEMSPACE}

The variables in the above macro names are upper-case and mangled-for-macro-use versions of the original type names. Here is a CMake rule for converting a type name into a name suitable for use either as a typedef used in a macro argument (macros don't like spaces, commas, etc.), or as part of a macro name (if made upper case).

FUNCTION(TPETRA_MANGLE_TEMPLATE_PARAMETER TYPE_MANGLED_OUT TYPE_IN)
  STRING(REPLACE "<" "0" TMP0 "${TYPE_IN}")
  STRING(REPLACE ">" "0" TMP1 "${TMP0}")
  STRING(REPLACE "::" "_" TMP2 "${TMP1}")
  # Spaces (as in "long long") get squished out.
  STRING(REPLACE " " "" TMP3 "${TMP2}")
  SET(${TYPE_MANGLED_OUT} ${TMP3} PARENT_SCOPE)
ENDFUNCTION(TPETRA_MANGLE_TEMPLATE_PARAMETER)

Summary of that rule:

  • < turns into 0
  • > turns into 0
  • :: turns into _
  • (space) turns into `` (empty string)

Here is a more Tpetra-specific CMake rule:

# Function that turns a valid Scalar, LocalOrdinal, or GlobalOrdinal
# template parameter into a macro name (all caps, with no white space
# and no punctuation other than underscore).
#
# NAME_OUT [out] The mangled type name.
#
# NAME_IN [in] The type to mangle.
FUNCTION(TPETRA_SLG_MACRO_NAME NAME_OUT NAME_IN)
  STRING(COMPARE EQUAL "${NAME_IN}" "__float128" IS_FLOAT128)
  IF(IS_FLOAT128)
    # __float128 is a special case; we remove the __ from the macro name.
    SET(${NAME_OUT} "FLOAT128" PARENT_SCOPE)
  ELSE()
    STRING(COMPARE EQUAL "${NAME_IN}" "std::complex<float>" IS_COMPLEX_FLOAT)
    IF(IS_COMPLEX_FLOAT)
      SET(${NAME_OUT} "COMPLEX_FLOAT" PARENT_SCOPE)
    ELSE()
      STRING(COMPARE EQUAL "${NAME_IN}" "std::complex<double>" IS_COMPLEX_DOUBLE)
      IF(IS_COMPLEX_DOUBLE)
        SET(${NAME_OUT} "COMPLEX_DOUBLE" PARENT_SCOPE)
      ELSE()
        # Make upper-case version of ${NAME_IN}.
        STRING(TOUPPER "${NAME_IN}" TMP0)
        # Use the generic algorithm for mangling the type name.
        TPETRA_MANGLE_TEMPLATE_PARAMETER(TMP1 "${TMP0}")
        SET(${NAME_OUT} ${TMP1} PARENT_SCOPE)
      ENDIF()
    ENDIF()
  ENDIF()
ENDFUNCTION(TPETRA_SLG_MACRO_NAME)
@mhoemmen
Copy link
Contributor Author

mhoemmen commented Apr 3, 2017

Hi @crtrott -- does #24 close this issue? Thanks! :-D

crtrott added a commit that referenced this issue Apr 4, 2017
This is necessary to handle cmake install better. Since
the number of generated header files is relatively small this
is not as bad as it would be for the cpp files.

This should largely resolve issue #21
@crtrott
Copy link
Member

crtrott commented Apr 4, 2017

Almost. I just fixed some installation issues and i think its now pretty close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants