frontend function to bypass cpu-id and to set arch_id #75
Comments
hfp
added a commit
that referenced
this issue
May 6, 2016
* Added libxsmm_set_target_arch and libxsmm_set_target_archid functions to the frontend (only stub impl. right now!). * Make sure libxsmm_get_target_arch() and libxsmm_get_target_archid() trigger lazy initialization.
hfp
added a commit
that referenced
this issue
May 14, 2016
…rst implementation to set target architecture at any time, however it affects only subsequent JIT compilations i.e., kernels which are not generated at this point. This functionality also does not allow to register any eventually available statically generated function according to the new arch-id. In fact, depending on the tool chain the first initialization of the library might have completed before any user code is able to set a different target architecture (GCC c'tor attribute). Added test case covering some basic assertions related to the target architecture. Refactored internal initialization to rely on the new setter function (LIBXSMM_JIT environment variable).
hfp
added a commit
that referenced
this issue
May 14, 2016
…th constrained (exhausted) code registry, the "jit" test case can fail without an actual problem. Removed test case (there is not much left over, which can be tested).
hfp
added a commit
that referenced
this issue
May 14, 2016
…corporated some debug-time warning about requested code path, which will fail to run on the actual target (CPUID check).
hfp
added a commit
that referenced
this issue
May 14, 2016
…rse all target id that can be produced according to the "enumeration" of target architectures (libxsmm_typedefs.h); previously missed: "x86" (LIBXSMM_X86_GENERIC), and "generic" (LIBXSMM_TARGET_ARCH_GENERIC).
hfp
added a commit
that referenced
this issue
May 14, 2016
…moved restriction to LEN=3 strings for the architecture id (FORTRAN).
hfp
added a commit
that referenced
this issue
May 17, 2016
…worked API which allows to get/set the target architecture: renamed libxsmm_get_target_archid <-> libxsmm_get_target_arch. Fixed function signatures (forbid arguments). Removed internal state which was tracking the name of the target architecture (now solely relying on target id). Introduced internal_get_target_arch function, which converts target id into target name. The latter simplifies a number of internal tasks, and fosters a single point of responsibility (code reuse). Fixed libxsmm_cpuid_x86 such that the code path cannot fall below LIBXSMM_STATIC_TARGET_ARCH.
hfp
added a commit
that referenced
this issue
May 17, 2016
…named LIBXSMM_JIT environment variable to LIBXSMM_TARGET and updated the documentation accordingly. Adjusted dispatch sample code to rely in target_arch API rather than parsing an environment variable. Updated interface documentation (C/C++ and FORTRAN). Clamped the result of libxsmm_get_target_archid in case the JIT backend is disabled at compile-time. Code cleanup.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be good to have not only a getter, but also a setter for the arch in LIBXSMM's frontend. This would allow the application to set the arch manually.
The text was updated successfully, but these errors were encountered: