impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Internal Jenkins (Code Review)" <>
Subject [Impala-CR](cdh5-trunk) IMPALA-775,IMPALA-3374: Upgrade LLVM to 3.8.0
Date Tue, 26 Apr 2016 07:57:06 GMT
Internal Jenkins has submitted this change and it was merged.

Change subject: IMPALA-775,IMPALA-3374: Upgrade LLVM to 3.8.0

IMPALA-775,IMPALA-3374: Upgrade LLVM to 3.8.0

This is the same as the previous LLVM upgrade patch, except we've
removed the libtinfo dependency, so we assume we're building against an
LLVM that doesn't require that.

This requires various changes for Impala to be fully functional with the
new version of LLVM.

The original JIT was removed from LLVM, we need to switch to the new
MCJIT API and implementation.

MCJIT only supports module-at-a-time compilation, so the module must
be finalised before any compilation happens. We didn't depend on the
old behaviour deeply, but various small fixes were required.

MCJIT requires that every IR module has a name.

We relied on the old JIT's workaround for the __dso_handle symbol,
which we have to emulate for MCJIT with a customer memory manager
until we can get rid of global initialisers in cross-compiled code.

LLVM made a number of incompatible API changes and reorganised headers.

Clang took over responsibility for padding structs by marking structs
as packed and inserting bytes so that members are aligned correctly
(previously it relies LLVM aligning struct members based on the
target's alignment rules). This means Impala also needs to manually
pad its structs since clang-emitted structs look to LLVM like they have
do not need to be inlined.

Our inlining pass would require some modification to work and is
redundant with LLVM's inlining pass, so was removed along with the
unused subexpr elimination pass.

There were various issues with __builtin_add_overflow and
__builtin_mul_overflow that are newly available in LLVM 3.8.
First, LLVM emitted a call to a function in libclang_rt, which
we don't link in and has symbols that conflict with
the gcc runtime library. Second, the performance actually regressed
by using the builtins (I tested this manually by copying across the
definition of the required function).

Change-Id: I60b18a40a2df3f1adf326721f0df2a639d53a7c2
Reviewed-by: Tim Armstrong <>
Tested-by: Internal Jenkins
M be/CMakeLists.txt
M be/src/benchmarks/
M be/src/benchmarks/
M be/src/codegen/CMakeLists.txt
M be/src/codegen/
M be/src/codegen/
M be/src/codegen/
M be/src/codegen/
M be/src/codegen/llvm-codegen.h
A be/src/codegen/mcjit-mem-mgr.h
D be/src/codegen/
D be/src/codegen/subexpr-elimination.h
M be/src/exec/
M be/src/exec/
M be/src/exec/
M be/src/exec/
M be/src/exec/
M be/src/exec/
M be/src/exec/
M be/src/exec/
M be/src/exec/
M be/src/exprs/
M be/src/exprs/
M be/src/exprs/
M be/src/exprs/
M be/src/runtime/decimal-value.inline.h
M be/src/runtime/
M be/src/runtime/descriptors.h
M be/src/runtime/
M be/src/runtime/
M bin/
M bin/
M cmake_modules/FindLlvm.cmake
33 files changed, 544 insertions(+), 757 deletions(-)

  Internal Jenkins: Verified
  Tim Armstrong: Looks good to me, approved

To view, visit
To unsubscribe, visit

Gerrit-MessageType: merged
Gerrit-Change-Id: I60b18a40a2df3f1adf326721f0df2a639d53a7c2
Gerrit-PatchSet: 2
Gerrit-Project: Impala
Gerrit-Branch: cdh5-trunk
Gerrit-Owner: Tim Armstrong <>
Gerrit-Reviewer: Dan Hecht <>
Gerrit-Reviewer: Internal Jenkins
Gerrit-Reviewer: Tim Armstrong <>

View raw message