2018-03-22 03:28:28 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
* llvmjit.h
|
|
|
|
* LLVM JIT provider.
|
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Copyright (c) 2016-2024, PostgreSQL Global Development Group
|
2018-03-22 03:28:28 +01:00
|
|
|
*
|
|
|
|
* src/include/jit/llvmjit.h
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef LLVMJIT_H
|
|
|
|
#define LLVMJIT_H
|
|
|
|
|
2019-01-29 03:05:52 +01:00
|
|
|
/*
|
|
|
|
* To avoid breaking cpluspluscheck, allow including the file even when LLVM
|
|
|
|
* is not available.
|
|
|
|
*/
|
|
|
|
#ifdef USE_LLVM
|
2018-03-22 03:28:28 +01:00
|
|
|
|
|
|
|
#include <llvm-c/Types.h>
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* File needs to be includable by both C and C++ code, and include other
|
|
|
|
* headers doing the same. Therefore wrap C portion in our own extern "C" if
|
|
|
|
* in C++ mode.
|
|
|
|
*/
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C"
|
|
|
|
{
|
|
|
|
#endif
|
|
|
|
|
2019-11-25 03:38:57 +01:00
|
|
|
#include "access/tupdesc.h"
|
2018-03-20 10:20:46 +01:00
|
|
|
#include "fmgr.h"
|
2018-03-22 03:28:28 +01:00
|
|
|
#include "jit/jit.h"
|
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
|
|
|
#include "nodes/pg_list.h"
|
2018-03-22 03:28:28 +01:00
|
|
|
|
|
|
|
typedef struct LLVMJitContext
|
|
|
|
{
|
|
|
|
JitContext base;
|
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
|
|
|
|
|
|
|
/* number of modules created */
|
|
|
|
size_t module_generation;
|
|
|
|
|
2023-09-27 13:02:21 +02:00
|
|
|
/*
|
|
|
|
* The LLVM Context used by this JIT context. An LLVM context is reused
|
|
|
|
* across many compilations, but occasionally reset to prevent it using
|
|
|
|
* too much memory due to more and more types accumulating.
|
|
|
|
*/
|
|
|
|
LLVMContextRef llvm_context;
|
|
|
|
|
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
|
|
|
/* current, "open for write", module */
|
|
|
|
LLVMModuleRef module;
|
|
|
|
|
|
|
|
/* is there any pending code that needs to be emitted */
|
|
|
|
bool compiled;
|
|
|
|
|
|
|
|
/* # of objects emitted, used to generate non-conflicting names */
|
|
|
|
int counter;
|
|
|
|
|
|
|
|
/* list of handles for code emitted via Orc */
|
|
|
|
List *handles;
|
2018-03-22 03:28:28 +01:00
|
|
|
} LLVMJitContext;
|
|
|
|
|
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
|
|
|
/* type and struct definitions */
|
2022-04-08 14:16:38 +02:00
|
|
|
extern PGDLLIMPORT LLVMTypeRef TypeParamBool;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef TypePGFunction;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef TypeSizeT;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef TypeStorageBool;
|
|
|
|
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructNullableDatum;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructTupleDescData;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructHeapTupleData;
|
jit: Support opaque pointers in LLVM 16.
Remove use of LLVMGetElementType() and provide the type of all pointers
to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM
versions[1].
* For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions.
* For LLVM == 15, we'll continue to do the same, explicitly opting
out of opaque pointer mode.
* For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take
the extra type argument.
The difference is hidden behind some new IR emitting wrapper functions
l_load(), l_gep(), l_call() etc. The change is mostly mechanical,
except that at each site the correct type had to be provided.
In some places we needed to do some extra work to get functions types,
including some new wrappers for C++ APIs that are not yet exposed by in
LLVM's C API, and some new "example" functions in llvmjit_types.c
because it's no longer possible to start from the function pointer type
and ask for the function type.
Back-patch to 12, because it's a little tricker in 11 and we agreed not
to put the latest LLVM support into the upcoming final release of 11.
[1] https://llvm.org/docs/OpaquePointers.html
Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com>
Reviewed-by: Ronan Dunklau <ronan.dunklau@aiven.io>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com
2023-10-18 11:09:05 +02:00
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructHeapTupleHeaderData;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructMinimalTupleData;
|
2022-04-08 14:16:38 +02:00
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructTupleTableSlot;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructHeapTupleTableSlot;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructMinimalTupleTableSlot;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructMemoryContextData;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructFunctionCallInfoData;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructExprContext;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructExprEvalStep;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructExprState;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructAggState;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructAggStatePerTransData;
|
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructAggStatePerGroupData;
|
jit: Support opaque pointers in LLVM 16.
Remove use of LLVMGetElementType() and provide the type of all pointers
to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM
versions[1].
* For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions.
* For LLVM == 15, we'll continue to do the same, explicitly opting
out of opaque pointer mode.
* For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take
the extra type argument.
The difference is hidden behind some new IR emitting wrapper functions
l_load(), l_gep(), l_call() etc. The change is mostly mechanical,
except that at each site the correct type had to be provided.
In some places we needed to do some extra work to get functions types,
including some new wrappers for C++ APIs that are not yet exposed by in
LLVM's C API, and some new "example" functions in llvmjit_types.c
because it's no longer possible to start from the function pointer type
and ask for the function type.
Back-patch to 12, because it's a little tricker in 11 and we agreed not
to put the latest LLVM support into the upcoming final release of 11.
[1] https://llvm.org/docs/OpaquePointers.html
Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com>
Reviewed-by: Ronan Dunklau <ronan.dunklau@aiven.io>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com
2023-10-18 11:09:05 +02:00
|
|
|
extern PGDLLIMPORT LLVMTypeRef StructPlanState;
|
2022-04-08 14:16:38 +02:00
|
|
|
|
|
|
|
extern PGDLLIMPORT LLVMValueRef AttributeTemplate;
|
jit: Support opaque pointers in LLVM 16.
Remove use of LLVMGetElementType() and provide the type of all pointers
to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM
versions[1].
* For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions.
* For LLVM == 15, we'll continue to do the same, explicitly opting
out of opaque pointer mode.
* For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take
the extra type argument.
The difference is hidden behind some new IR emitting wrapper functions
l_load(), l_gep(), l_call() etc. The change is mostly mechanical,
except that at each site the correct type had to be provided.
In some places we needed to do some extra work to get functions types,
including some new wrappers for C++ APIs that are not yet exposed by in
LLVM's C API, and some new "example" functions in llvmjit_types.c
because it's no longer possible to start from the function pointer type
and ask for the function type.
Back-patch to 12, because it's a little tricker in 11 and we agreed not
to put the latest LLVM support into the upcoming final release of 11.
[1] https://llvm.org/docs/OpaquePointers.html
Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com>
Reviewed-by: Ronan Dunklau <ronan.dunklau@aiven.io>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com
2023-10-18 11:09:05 +02:00
|
|
|
extern PGDLLIMPORT LLVMValueRef ExecEvalBoolSubroutineTemplate;
|
|
|
|
extern PGDLLIMPORT LLVMValueRef ExecEvalSubroutineTemplate;
|
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
|
|
|
|
|
|
|
|
2018-03-22 03:28:28 +01:00
|
|
|
extern void llvm_enter_fatal_on_oom(void);
|
|
|
|
extern void llvm_leave_fatal_on_oom(void);
|
2021-09-14 03:07:19 +02:00
|
|
|
extern bool llvm_in_fatal_on_oom(void);
|
2018-03-22 03:28:28 +01:00
|
|
|
extern void llvm_reset_after_error(void);
|
|
|
|
extern void llvm_assert_in_fatal_section(void);
|
|
|
|
|
|
|
|
extern LLVMJitContext *llvm_create_context(int jitFlags);
|
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
|
|
|
extern LLVMModuleRef llvm_mutable_module(LLVMJitContext *context);
|
|
|
|
extern char *llvm_expand_funcname(LLVMJitContext *context, const char *basename);
|
|
|
|
extern void *llvm_get_function(LLVMJitContext *context, const char *funcname);
|
|
|
|
extern void llvm_split_symbol_name(const char *name, char **modname, char **funcname);
|
2020-12-07 22:16:55 +01:00
|
|
|
extern LLVMTypeRef llvm_pg_var_type(const char *varname);
|
|
|
|
extern LLVMTypeRef llvm_pg_var_func_type(const char *varname);
|
2020-02-07 07:13:52 +01:00
|
|
|
extern LLVMValueRef llvm_pg_func(LLVMModuleRef mod, const char *funcname);
|
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
|
|
|
extern void llvm_copy_attributes(LLVMValueRef from, LLVMValueRef to);
|
2018-03-20 10:20:46 +01:00
|
|
|
extern LLVMValueRef llvm_function_reference(LLVMJitContext *context,
|
|
|
|
LLVMBuilderRef builder,
|
|
|
|
LLVMModuleRef mod,
|
|
|
|
FunctionCallInfo fcinfo);
|
2018-03-22 03:28:28 +01:00
|
|
|
|
2023-09-27 13:02:21 +02:00
|
|
|
extern void llvm_inline_reset_caches(void);
|
2018-03-28 22:19:08 +02:00
|
|
|
extern void llvm_inline(LLVMModuleRef mod);
|
2018-03-22 03:44:17 +01:00
|
|
|
|
2018-03-20 10:20:46 +01:00
|
|
|
/*
|
|
|
|
****************************************************************************
|
2018-04-01 21:01:28 +02:00
|
|
|
* Code generation functions.
|
2018-03-20 10:20:46 +01:00
|
|
|
****************************************************************************
|
|
|
|
*/
|
|
|
|
extern bool llvm_compile_expr(struct ExprState *state);
|
2018-11-16 07:00:30 +01:00
|
|
|
struct TupleTableSlotOps;
|
|
|
|
extern LLVMValueRef slot_compile_deform(struct LLVMJitContext *context, TupleDesc desc,
|
|
|
|
const struct TupleTableSlotOps *ops, int natts);
|
2018-03-20 10:20:46 +01:00
|
|
|
|
2018-03-22 03:44:17 +01:00
|
|
|
/*
|
|
|
|
****************************************************************************
|
|
|
|
* Extensions / Backward compatibility section of the LLVM C API
|
|
|
|
* Error handling related functions.
|
|
|
|
****************************************************************************
|
|
|
|
*/
|
jit: Support opaque pointers in LLVM 16.
Remove use of LLVMGetElementType() and provide the type of all pointers
to LLVMBuildXXX() functions when emitting IR, as required by modern LLVM
versions[1].
* For LLVM <= 14, we'll still use the old LLVMBuildXXX() functions.
* For LLVM == 15, we'll continue to do the same, explicitly opting
out of opaque pointer mode.
* For LLVM >= 16, we'll use the new LLVMBuildXXX2() functions that take
the extra type argument.
The difference is hidden behind some new IR emitting wrapper functions
l_load(), l_gep(), l_call() etc. The change is mostly mechanical,
except that at each site the correct type had to be provided.
In some places we needed to do some extra work to get functions types,
including some new wrappers for C++ APIs that are not yet exposed by in
LLVM's C API, and some new "example" functions in llvmjit_types.c
because it's no longer possible to start from the function pointer type
and ask for the function type.
Back-patch to 12, because it's a little tricker in 11 and we agreed not
to put the latest LLVM support into the upcoming final release of 11.
[1] https://llvm.org/docs/OpaquePointers.html
Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com>
Reviewed-by: Ronan Dunklau <ronan.dunklau@aiven.io>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/CA%2BhUKGKNX_%3Df%2B1C4r06WETKTq0G4Z_7q4L4Fxn5WWpMycDj9Fw%40mail.gmail.com
2023-10-18 11:09:05 +02:00
|
|
|
extern LLVMTypeRef LLVMGetFunctionReturnType(LLVMValueRef r);
|
|
|
|
extern LLVMTypeRef LLVMGetFunctionType(LLVMValueRef r);
|
2020-10-16 02:38:00 +02:00
|
|
|
|
2018-03-22 03:28:28 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
} /* extern "C" */
|
|
|
|
#endif
|
|
|
|
|
2019-01-29 03:05:52 +01:00
|
|
|
#endif /* USE_LLVM */
|
2018-03-22 03:28:28 +01:00
|
|
|
#endif /* LLVMJIT_H */
|