2018-03-22 03:28:28 +01:00
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
#
|
|
|
|
# Makefile--
|
|
|
|
# Makefile the LLVM JIT provider, building it into a shared library.
|
|
|
|
#
|
|
|
|
# Note that this file is recursed into from src/Makefile, not by the
|
|
|
|
# parent directory..
|
|
|
|
#
|
|
|
|
# IDENTIFICATION
|
|
|
|
# src/backend/jit/llvm/Makefile
|
|
|
|
#
|
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
|
|
|
subdir = src/backend/jit/llvm
|
|
|
|
top_builddir = ../../../..
|
|
|
|
include $(top_builddir)/src/Makefile.global
|
|
|
|
|
|
|
|
ifneq ($(with_llvm), yes)
|
|
|
|
$(error "not building with LLVM support")
|
|
|
|
endif
|
|
|
|
|
|
|
|
PGFILEDESC = "llvmjit - JIT using LLVM"
|
|
|
|
NAME = llvmjit
|
|
|
|
|
2022-03-15 22:30:55 +01:00
|
|
|
# LLVM 14 produces deprecation warnings. We'll need to make some changes
|
|
|
|
# before the relevant functions are removed, but for now silence the warnings.
|
|
|
|
ifeq ($(GCC), yes)
|
|
|
|
LLVM_CFLAGS += -Wno-deprecated-declarations
|
|
|
|
endif
|
|
|
|
|
2019-06-17 09:13:16 +02:00
|
|
|
# All files in this directory use LLVM.
|
2018-03-22 03:28:28 +01:00
|
|
|
CFLAGS += $(LLVM_CFLAGS)
|
|
|
|
CXXFLAGS += $(LLVM_CXXFLAGS)
|
|
|
|
override CPPFLAGS := $(LLVM_CPPFLAGS) $(CPPFLAGS)
|
|
|
|
SHLIB_LINK += $(LLVM_LIBS)
|
|
|
|
|
|
|
|
# Because this module includes C++ files, we need to use a C++
|
|
|
|
# compiler for linking. Makefile.shlib uses $(COMPILER) to build
|
|
|
|
# loadable modules.
|
|
|
|
override COMPILER = $(CXX) $(CFLAGS)
|
|
|
|
|
2019-11-05 23:41:07 +01:00
|
|
|
OBJS = \
|
|
|
|
$(WIN32RES)
|
2018-03-22 03:28:28 +01:00
|
|
|
|
|
|
|
# Infrastructure
|
2019-11-05 23:41:07 +01:00
|
|
|
OBJS += \
|
|
|
|
llvmjit.o \
|
|
|
|
llvmjit_error.o \
|
|
|
|
llvmjit_inline.o \
|
|
|
|
llvmjit_wrap.o
|
|
|
|
|
2018-03-22 03:28:28 +01:00
|
|
|
# Code generation
|
2019-11-05 23:41:07 +01:00
|
|
|
OBJS += \
|
|
|
|
llvmjit_deform.o \
|
|
|
|
llvmjit_expr.o
|
2018-03-22 03:28:28 +01:00
|
|
|
|
Support for optimizing and emitting code in LLVM JIT provider.
This commit introduces the ability to actually generate code using
LLVM. In particular, this adds:
- Ability to emit code both in heavily optimized and largely
unoptimized fashion
- Batching facility to allow functions to be defined in small
increments, but optimized and emitted in executable form in larger
batches (for performance and memory efficiency)
- Type and function declaration synchronization between runtime
generated code and normal postgres code. This is critical to be able
to access struct fields etc.
- Developer oriented jit_dump_bitcode GUC, for inspecting / debugging
the generated code.
- per JitContext statistics of number of functions, time spent
generating code, optimizing, and emitting it. This will later be
employed for EXPLAIN support.
This commit doesn't yet contain any code actually generating
functions. That'll follow in later commits.
Documentation for GUCs added, and for JIT in general, will be added in
later commits.
Author: Andres Freund, with contributions by Pierre Ducroquet
Testing-By: Thomas Munro, Peter Eisentraut
Discussion: https://postgr.es/m/20170901064131.tazjxwus3k2w3ybh@alap3.anarazel.de
2018-03-22 19:05:22 +01:00
|
|
|
all: all-shared-lib llvmjit_types.bc
|
2018-03-22 03:28:28 +01:00
|
|
|
|
Support for optimizing and emitting code in LLVM JIT provider.
This commit introduces the ability to actually generate code using
LLVM. In particular, this adds:
- Ability to emit code both in heavily optimized and largely
unoptimized fashion
- Batching facility to allow functions to be defined in small
increments, but optimized and emitted in executable form in larger
batches (for performance and memory efficiency)
- Type and function declaration synchronization between runtime
generated code and normal postgres code. This is critical to be able
to access struct fields etc.
- Developer oriented jit_dump_bitcode GUC, for inspecting / debugging
the generated code.
- per JitContext statistics of number of functions, time spent
generating code, optimizing, and emitting it. This will later be
employed for EXPLAIN support.
This commit doesn't yet contain any code actually generating
functions. That'll follow in later commits.
Documentation for GUCs added, and for JIT in general, will be added in
later commits.
Author: Andres Freund, with contributions by Pierre Ducroquet
Testing-By: Thomas Munro, Peter Eisentraut
Discussion: https://postgr.es/m/20170901064131.tazjxwus3k2w3ybh@alap3.anarazel.de
2018-03-22 19:05:22 +01:00
|
|
|
install: all installdirs install-lib install-types
|
2018-03-22 03:28:28 +01:00
|
|
|
|
|
|
|
installdirs: installdirs-lib
|
|
|
|
|
Support for optimizing and emitting code in LLVM JIT provider.
This commit introduces the ability to actually generate code using
LLVM. In particular, this adds:
- Ability to emit code both in heavily optimized and largely
unoptimized fashion
- Batching facility to allow functions to be defined in small
increments, but optimized and emitted in executable form in larger
batches (for performance and memory efficiency)
- Type and function declaration synchronization between runtime
generated code and normal postgres code. This is critical to be able
to access struct fields etc.
- Developer oriented jit_dump_bitcode GUC, for inspecting / debugging
the generated code.
- per JitContext statistics of number of functions, time spent
generating code, optimizing, and emitting it. This will later be
employed for EXPLAIN support.
This commit doesn't yet contain any code actually generating
functions. That'll follow in later commits.
Documentation for GUCs added, and for JIT in general, will be added in
later commits.
Author: Andres Freund, with contributions by Pierre Ducroquet
Testing-By: Thomas Munro, Peter Eisentraut
Discussion: https://postgr.es/m/20170901064131.tazjxwus3k2w3ybh@alap3.anarazel.de
2018-03-22 19:05:22 +01:00
|
|
|
uninstall: uninstall-lib uninstall-types
|
|
|
|
|
|
|
|
# Note this is intentionally not in bitcodedir, as it's not for inlining */
|
|
|
|
install-types: llvmjit_types.bc
|
|
|
|
$(INSTALL_DATA) llvmjit_types.bc '$(DESTDIR)$(pkglibdir)'
|
|
|
|
|
|
|
|
uninstall-types:
|
|
|
|
rm -f '$(DESTDIR)$(pkglibdir)/llvmjit_types.bc'
|
2018-03-22 03:28:28 +01:00
|
|
|
|
|
|
|
include $(top_srcdir)/src/Makefile.shlib
|
|
|
|
|
Remove distprep
A PostgreSQL release tarball contains a number of prebuilt files, in
particular files produced by bison, flex, perl, and well as html and
man documentation. We have done this consistent with established
practice at the time to not require these tools for building from a
tarball. Some of these tools were hard to get, or get the right
version of, from time to time, and shipping the prebuilt output was a
convenience to users.
Now this has at least two problems:
One, we have to make the build system(s) work in two modes: Building
from a git checkout and building from a tarball. This is pretty
complicated, but it works so far for autoconf/make. It does not
currently work for meson; you can currently only build with meson from
a git checkout. Making meson builds work from a tarball seems very
difficult or impossible. One particular problem is that since meson
requires a separate build directory, we cannot make the build update
files like gram.h in the source tree. So if you were to build from a
tarball and update gram.y, you will have a gram.h in the source tree
and one in the build tree, but the way things work is that the
compiler will always use the one in the source tree. So you cannot,
for example, make any gram.y changes when building from a tarball.
This seems impossible to fix in a non-horrible way.
Second, there is increased interest nowadays in precisely tracking the
origin of software. We can reasonably track contributions into the
git tree, and users can reasonably track the path from a tarball to
packages and downloads and installs. But what happens between the git
tree and the tarball is obscure and in some cases non-reproducible.
The solution for both of these issues is to get rid of the step that
adds prebuilt files to the tarball. The tarball now only contains
what is in the git tree (*). Getting the additional build
dependencies is no longer a problem nowadays, and the complications to
keep these dual build modes working are significant. And of course we
want to get the meson build system working universally.
This commit removes the make distprep target altogether. The make
dist target continues to do its job, it just doesn't call distprep
anymore.
(*) - The tarball also contains the INSTALL file that is built at make
dist time, but not by distprep. This is unchanged for now.
The make maintainer-clean target, whose job it is to remove the
prebuilt files in addition to what make distclean does, is now just an
alias to make distprep. (In practice, it is probably obsolete given
that git clean is available.)
The following programs are now hard build requirements in configure
(they were already required by meson.build):
- bison
- flex
- perl
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://www.postgresql.org/message-id/flat/e07408d9-e5f2-d9fd-5672-f53354e9305e@eisentraut.org
2023-11-06 14:51:52 +01:00
|
|
|
clean distclean: clean-lib
|
2018-03-22 03:28:28 +01:00
|
|
|
rm -f $(OBJS)
|
Support for optimizing and emitting code in LLVM JIT provider.
This commit introduces the ability to actually generate code using
LLVM. In particular, this adds:
- Ability to emit code both in heavily optimized and largely
unoptimized fashion
- Batching facility to allow functions to be defined in small
increments, but optimized and emitted in executable form in larger
batches (for performance and memory efficiency)
- Type and function declaration synchronization between runtime
generated code and normal postgres code. This is critical to be able
to access struct fields etc.
- Developer oriented jit_dump_bitcode GUC, for inspecting / debugging
the generated code.
- per JitContext statistics of number of functions, time spent
generating code, optimizing, and emitting it. This will later be
employed for EXPLAIN support.
This commit doesn't yet contain any code actually generating
functions. That'll follow in later commits.
Documentation for GUCs added, and for JIT in general, will be added in
later commits.
Author: Andres Freund, with contributions by Pierre Ducroquet
Testing-By: Thomas Munro, Peter Eisentraut
Discussion: https://postgr.es/m/20170901064131.tazjxwus3k2w3ybh@alap3.anarazel.de
2018-03-22 19:05:22 +01:00
|
|
|
rm -f llvmjit_types.bc
|