On Improving the Build System revisited

Has anyone started on integrating the openmp build into the llvm build yet? If not, I would suggest we start by borrowing the build machinery files from polly as the starting point. Like polly, openmp provides a support library for the compiler and should be built in the tools subdirectory… Also, the polly cmake and autogen directories are fairly spartan so they should be easy to refashion for openmp.
Jack

    Has anyone started on integrating the openmp build into the llvm build yet? If not, I would suggest we start by borrowing the build machinery files from polly as the starting point. Like polly, openmp provides a support library for the compiler and should be built in the tools subdirectory..

Polly is completely different to the OpenMP runtime. Polly uses LLVM libraries, and can be seen as part of the compilation host toolchain, while this is an independent runtime library that runs on the target. So the build systems are tangential.

Also, the polly cmake and autogen directories are fairly spartan so they should be easy to refashion for openmp.

There's a simple CMake setup on one of the GitHub branches of this project, C. Bergström may know better if they can be contributed. Either way that's closer to what's needed here.

Alp.

Alp,
Do you mean by this project, llvm, or the general openmp project across the various compilers? A google search isn’t showing any promising leads on locating this branch.
Jack

Why not structure this as an LLVM "project" as defined in http://llvm.org/docs/Projects.html?

John D. Leidel

Should it be an out of source build like libcxx?

Should it be an out of source build like libcxx?

Yep, exactly.

Will try to dig up the CMake files, they're pretty neat. Some Intel/icc-specific functionality is missing IIRC but otherwise fine.

Alp.

Alp,
Are you thinking of these?

https://github.com/pathscale/openmprtl/blob/master/itt/libomp_oss/CMakeLists.txt

Jack
ps Worse case we can at least look at those as a template on how to construct ours.

Using the overall file locations and structure from the openmprtl site, this shouldn’t be that hard to set the cmake build machinery up. For example, the Cmakefiles.txt in openmp-3.5.0/runtime would just be something like…

cmake_minimum_required(VERSION 2.8.1)

project(libiomp)

enable_language(C ASM)

set(VERSION 5)
set(OMP_VERSION_NUM “40”)

set debug as default build

if("${BUILD_TYPE}" STREQUAL “”)
set(BUILD_TYPE “Debug”)
endif()

set 64bit as default architecture

if("${ARCH}" STREQUAL “”)
set(ARCH “32e”)
endif()
set(ARCH_STR “Intel(R) 64”)

set(COMMON_FLAGS “${COMMON_FLAGS} -D USE_ITT_BUILD”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D NDEBUG”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D KMP_ARCH_STR=”\"${ARCH_STR}\""")
set(COMMON_FLAGS “${COMMON_FLAGS} -D _GNU_SOURCE”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D _REENTRANT”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D KMP_USE_ASSERT”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D BUILD_I8”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D BUILD_TV”)
if(APPLE)
set(COMMON_FLAGS “${COMMON_FLAGS} -D KMP_LIBRARY_FILE=\“libiomp5.dylib\””)
else()
set(COMMON_FLAGS “${COMMON_FLAGS} -D KMP_LIBRARY_FILE=\“libiomp5.so\””)
endif()
set(COMMON_FLAGS “${COMMON_FLAGS} -D KMP_VERSION_MAJOR=${VERSION}”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D CACHE_LINE=64”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D KMP_ADJUST_BLOCKTIME=1”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D BUILD_PARALLEL_ORDERED”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D KMP_ASM_INTRINS”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D USE_LOAD_BALANCE”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D USE_CBLKDATA”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D GUIDEDLL_EXPORTS”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D KMP_GOMP_COMPAT”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D KMP_USE_ADAPTIVE_LOCKS=1”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D KMP_DEBUG_ADAPTIVE_LOCKS=0”)

if("${OMP_VERSION_NUM}" STREQUAL “40”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D OMP_50_ENABLED=0”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D OMP_41_ENABLED=0”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D OMP_40_ENABLED=1”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D OMP_30_ENABLED=1”)
endif()

set(COMMON_FLAGS “${COMMON_FLAGS} -D USE_ITT_NOTIFY=1”)
set(COMMON_FLAGS “${COMMON_FLAGS} -D INTEL_ITTNOTIFY_PREFIX=_kmp_itt”)

set(C_CXX_COMMON_FLAGS “${C_CXX_COMMON_FLAGS} -fPIC”)

if(${BUILD_TYPE} STREQUAL “Debug”)
set(COMMON_FLAGS “${COMMON_FLAGS} -g”)
endif()

Silence some warnings

set(C_CXX_COMMON_FLAGS “${C_CXX_COMMON_FLAGS} -Wno-unused-value”)
set(C_CXX_COMMON_FLAGS “${C_CXX_COMMON_FLAGS} -Wno-switch”)
set(C_CXX_COMMON_FLAGS “${C_CXX_COMMON_FLAGS} -Wno-switch”)

Disable exception handling.

set(C_CXX_COMMON_FLAGS “${C_CXX_COMMON_FLAGS} -fno-exceptions”)

Disable use of EBP as general purpose register.

if(NOT ${ARCH} STREQUAL “64”)
set(C_CXX_COMMON_FLAGS “${C_CXX_COMMON_FLAGS} -fno-omit-frame-pointer”)
endif()

set(CMAKE_C_FLAGS “${CMAKE_C_FLAGS} ${COMMON_FLAGS} ${C_CXX_COMMON_FLAGS}”)
set(CMAKE_CXX_FLAGS “${CMAKE_CXX_FLAGS} ${COMMON_FLAGS} ${C_CXX_COMMON_FLAGS}”)

add_subdirectory(src)

IMHO, I don’t think there is much intellectual property here as it is a fairly standard cmake syntax which is adjusted to mimic the flags emitted by the current build.pl scripts (which is how I made my adjustments anyway).
Jack

Likewise the Cmakefiles.txt in openmp-3.5.0/runtime/src would be modified as…

cmake_minimum_required(VERSION 2.8.1)

include_directories(
.
include
include/${OMP_VERSION_NUM}
i18n
thirdparty/ittnotify
${CMAKE_CURRENT_BINARY_DIR}
)

set(ASM_SRCS
z_Linux_asm.S
)

set(SRCS
z_Linux_util.c
kmp_version.c
kmp_utility.c
kmp_threadprivate.c
kmp_taskq.c
kmp_tasking.c
kmp_taskdeps.cpp
kmp_str.c
kmp_settings.c
kmp_sched.cpp
kmp_runtime.c
kmp_lock.cpp
kmp_itt.c
kmp_io.c
kmp_i18n.c
kmp_gsupport.c
kmp_global.c
kmp_ftn_extra.c
kmp_ftn_cdecl.c
kmp_error.c
kmp_environment.c
kmp_dispatch.cpp
kmp_debug.c
kmp_csupport.c
kmp_cancel.cpp
kmp_atomic.c
kmp_alloc.c
kmp_affinity.cpp
…/thirdparty/innotify/ittnotify_static.c
)

set_source_files_properties(${SRCS} PROPERTIES LANGUAGE CXX)

set_source_files_properties(${ASM_SRCS} PROPERTIES LANGUAGE CXX)
set_source_files_properties(${ASM_SRCS} PROPERTIES COMPILE_FLAGS “-DKMP_GOMP_COMPAT -DKMP_ARCH_X86_64 -x assembler-with-cpp”)

TODO: config parameter

if(WIN32)
set(OS_GEN “win”)
elseif(UNIX)
set(OS_GEN “lin”)
elseif(APPLE)
set(OS_GEN “mac”)
endif()

add_custom_command(
OUTPUT kmp_i18n_id.inc
COMMAND perl ${CMAKE_CURRENT_SOURCE_DIR}/…/tools/message-converter.pl --os=${OS_GEN} --arch=${ARCH} --prefix=kmp_i18n --enum=kmp_i18n_id.inc ${CMAKE_CURRENT_SOURCE_DIR}/i18n/en_US.txt
)
add_custom_command(
OUTPUT kmp_i18n_default.inc
COMMAND perl ${CMAKE_CURRENT_SOURCE_DIR}/…/tools/message-converter.pl --os=${OS_GEN} --arch=${ARCH} --prefix=kmp_i18n --default=kmp_i18n_default.inc ${CMAKE_CURRENT_SOURCE_DIR}/i18n/en_US.txt
)
add_custom_command(
OUTPUT omp.h
COMMAND perl ${CMAKE_CURRENT_SOURCE_DIR}/…/tools/expand-vars.pl --strict -D Revision="\$$Revision" -D Date="\$$Date" -D KMP_TYPE=“Performance” -D KMP_ARCH="\"${ARCH_STR}\"" -D KMP_VERSION_MAJOR=${VERSION} -D KMP_VERSION_MINOR=0 -D KMP_VERSION_BUILD=00000000 -D KMP_BUILD_DATE="${BUILD_TIME} UTC" -D KMP_TARGET_COMPILER=12 -D KMP_DIAG=0 -D KMP_DEBUG_INFO=0 -D OMP_VERSION=${OMP_VERSION} ${CMAKE_CURRENT_SOURCE_DIR}/include/${OMP_VERSION_NUM}/omp.h.var omp.h
)
add_custom_command(
OUTPUT z_Linux_asm.o
COMMAND g++ -c -o z_Linux_asm.o -DKMP_GOMP_COMPAT -DKMP_ARCH_X86_64 -x assembler-with-cpp ${CMAKE_CURRENT_SOURCE_DIR}/${ASM_SRCS}
)

add_custom_target(gen_kmp_i18n DEPENDS kmp_i18n_id.inc kmp_i18n_default.inc omp.h z_Linux_asm.o)

add_library(iomp5 SHARED ${SRCS} z_Linux_asm.o)
add_dependencies(iomp5 gen_kmp_i18n)

install(FILES ${CMAKE_CURRENT_BINARY_DIR}/omp.h
DESTINATION include/${PSC_FULL_VERSION})

foreach(targ ${PATH64_ENABLE_TARGETS})
set(targ_arch ${PATH64_TARGET_ARCH${targ}})
set(targ_bits ${PATH64_TARGET_BITS${targ}})
install(FILES ${CMAKE_BINARY_DIR}/Xcompiler/lib/libiomp5.so
DESTINATION ${PATH64_LIB_PATH}/${targ_arch}/${targ_bits})
endforeach()

…which still needs expanded to handle the fact that darwin builds this twice at 64 and 32 bit for a fat binary of the shared library. I don’t think there is a lot of leeway in constructing such cmake files are they are simply duplicating the commands emitted by build.pl.
Jack

Yes, these CMake lists looks really good and I have them integrated locally here with LLVM ToT.

We'll maintain this in parallel along with the existing build system for some time so the CMake setup doesn't have to be feature-complete from the get go.

LLVM project rules are however that we need explicit contribution from the author/owner of the code -- having the right license isn't sufficient and it's not really trivial code. Some time back I was speaking with people involved and indications were good but it needs to be chased up.

Jack, could you investigate that, and then we can finalize the integration work when there's a sign-off?

Thanks for working on this

Alp.

Alp,
I emailed Andrey Bokhanko at Intel to find out if there was any issues with llvm.org using those as templates. My argument was, since these files simply duplicate the commands emitted by build.pl, that any cmake file written from scratch is bound to look very similar.
Jack

We’re hoping to push code with CMAKE files for building the runtime “real soon now”, so you may want to hold off for a week or so…

– Jim

James Cownie <james.h.cownie@intel.com>
SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)

Tel: +44 117 9071438