2018-03-26 21:57:19 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* llvmjit_deform.c
|
|
|
|
* Generate code for deforming a heap tuple.
|
|
|
|
*
|
|
|
|
* This gains performance benefits over unJITed deforming from compile-time
|
|
|
|
* knowledge of the tuple descriptor. Fixed column widths, NOT NULLness, etc
|
|
|
|
* can be taken advantage of.
|
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2018-03-26 21:57:19 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/backend/jit/llvm/llvmjit_deform.c
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include <llvm-c/Core.h>
|
|
|
|
|
|
|
|
#include "access/htup_details.h"
|
2018-03-28 06:03:10 +02:00
|
|
|
#include "access/tupdesc_details.h"
|
2018-03-26 21:57:19 +02:00
|
|
|
#include "executor/tuptable.h"
|
|
|
|
#include "jit/llvmjit.h"
|
|
|
|
#include "jit/llvmjit_emit.h"
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a function that deforms a tuple of type desc up to natts columns.
|
|
|
|
*/
|
|
|
|
LLVMValueRef
|
2018-11-16 07:00:30 +01:00
|
|
|
slot_compile_deform(LLVMJitContext *context, TupleDesc desc,
|
|
|
|
const TupleTableSlotOps *ops, int natts)
|
2018-03-26 21:57:19 +02:00
|
|
|
{
|
|
|
|
char *funcname;
|
|
|
|
|
|
|
|
LLVMModuleRef mod;
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMContextRef lc;
|
2018-03-26 21:57:19 +02:00
|
|
|
LLVMBuilderRef b;
|
|
|
|
|
|
|
|
LLVMTypeRef deform_sig;
|
|
|
|
LLVMValueRef v_deform_fn;
|
|
|
|
|
|
|
|
LLVMBasicBlockRef b_entry;
|
|
|
|
LLVMBasicBlockRef b_adjust_unavail_cols;
|
|
|
|
LLVMBasicBlockRef b_find_start;
|
|
|
|
|
|
|
|
LLVMBasicBlockRef b_out;
|
|
|
|
LLVMBasicBlockRef b_dead;
|
|
|
|
LLVMBasicBlockRef *attcheckattnoblocks;
|
|
|
|
LLVMBasicBlockRef *attstartblocks;
|
|
|
|
LLVMBasicBlockRef *attisnullblocks;
|
|
|
|
LLVMBasicBlockRef *attcheckalignblocks;
|
|
|
|
LLVMBasicBlockRef *attalignblocks;
|
|
|
|
LLVMBasicBlockRef *attstoreblocks;
|
|
|
|
|
|
|
|
LLVMValueRef v_offp;
|
|
|
|
|
|
|
|
LLVMValueRef v_tupdata_base;
|
|
|
|
LLVMValueRef v_tts_values;
|
|
|
|
LLVMValueRef v_tts_nulls;
|
|
|
|
LLVMValueRef v_slotoffp;
|
2018-10-16 00:24:33 +02:00
|
|
|
LLVMValueRef v_flagsp;
|
2018-03-26 21:57:19 +02:00
|
|
|
LLVMValueRef v_nvalidp;
|
|
|
|
LLVMValueRef v_nvalid;
|
|
|
|
LLVMValueRef v_maxatt;
|
|
|
|
|
|
|
|
LLVMValueRef v_slot;
|
|
|
|
|
|
|
|
LLVMValueRef v_tupleheaderp;
|
|
|
|
LLVMValueRef v_tuplep;
|
|
|
|
LLVMValueRef v_infomask1;
|
|
|
|
LLVMValueRef v_infomask2;
|
|
|
|
LLVMValueRef v_bits;
|
|
|
|
|
|
|
|
LLVMValueRef v_hoff;
|
|
|
|
|
|
|
|
LLVMValueRef v_hasnulls;
|
|
|
|
|
|
|
|
/* last column (0 indexed) guaranteed to exist */
|
|
|
|
int guaranteed_column_number = -1;
|
|
|
|
|
|
|
|
/* current known alignment */
|
|
|
|
int known_alignment = 0;
|
|
|
|
|
|
|
|
/* if true, known_alignment describes definite offset of column */
|
|
|
|
bool attguaranteedalign = true;
|
|
|
|
|
|
|
|
int attnum;
|
|
|
|
|
2018-11-16 07:00:30 +01:00
|
|
|
/* virtual tuples never need deforming, so don't generate code */
|
|
|
|
if (ops == &TTSOpsVirtual)
|
|
|
|
return NULL;
|
|
|
|
|
Make TupleTableSlots extensible, finish split of existing slot type.
This commit completes the work prepared in 1a0586de36, splitting the
old TupleTableSlot implementation (which could store buffer, heap,
minimal and virtual slots) into four different slot types. As
described in the aforementioned commit, this is done with the goal of
making tuple table slots extensible, to allow for pluggable table
access methods.
To achieve runtime extensibility for TupleTableSlots, operations on
slots that can differ between types of slots are performed using the
TupleTableSlotOps struct provided at slot creation time. That
includes information from the size of TupleTableSlot struct to be
allocated, initialization, deforming etc. See the struct's definition
for more detailed information about callbacks TupleTableSlotOps.
I decided to rename TTSOpsBufferTuple to TTSOpsBufferHeapTuple and
ExecCopySlotTuple to ExecCopySlotHeapTuple, as that seems more
consistent with other naming introduced in recent patches.
There's plenty optimization potential in the slot implementation, but
according to benchmarking the state after this commit has similar
performance characteristics to before this set of changes, which seems
sufficient.
There's a few changes in execReplication.c that currently need to poke
through the slot abstraction, that'll be repaired once the pluggable
storage patchset provides the necessary infrastructure.
Author: Andres Freund and Ashutosh Bapat, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-17 01:35:11 +01:00
|
|
|
/* decline to JIT for slot types we don't know to handle */
|
|
|
|
if (ops != &TTSOpsHeapTuple && ops != &TTSOpsBufferHeapTuple &&
|
|
|
|
ops != &TTSOpsMinimalTuple)
|
|
|
|
return NULL;
|
|
|
|
|
2018-03-26 21:57:19 +02:00
|
|
|
mod = llvm_mutable_module(context);
|
2023-09-27 13:02:21 +02:00
|
|
|
lc = LLVMGetModuleContext(mod);
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
funcname = llvm_expand_funcname(context, "deform");
|
|
|
|
|
|
|
|
/*
|
2019-05-01 00:55:07 +02:00
|
|
|
* Check which columns have to exist, so we don't have to check the row's
|
|
|
|
* natts unnecessarily.
|
2018-03-26 21:57:19 +02:00
|
|
|
*/
|
|
|
|
for (attnum = 0; attnum < desc->natts; attnum++)
|
|
|
|
{
|
2018-03-28 06:03:10 +02:00
|
|
|
Form_pg_attribute att = TupleDescAttr(desc, attnum);
|
|
|
|
|
|
|
|
/*
|
2019-05-01 00:55:07 +02:00
|
|
|
* If the column is declared NOT NULL then it must be present in every
|
|
|
|
* tuple, unless there's a "missing" entry that could provide a
|
|
|
|
* non-NULL value for it. That in turn guarantees that the NULL bitmap
|
|
|
|
* - if there are any NULLable columns - is at least long enough to
|
|
|
|
* cover columns up to attnum.
|
|
|
|
*
|
|
|
|
* Be paranoid and also check !attisdropped, even though the
|
|
|
|
* combination of attisdropped && attnotnull combination shouldn't
|
|
|
|
* exist.
|
2018-03-28 06:03:10 +02:00
|
|
|
*/
|
2019-05-01 00:55:07 +02:00
|
|
|
if (att->attnotnull &&
|
|
|
|
!att->atthasmissing &&
|
|
|
|
!att->attisdropped)
|
2018-03-26 21:57:19 +02:00
|
|
|
guaranteed_column_number = attnum;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Create the signature and function */
|
|
|
|
{
|
|
|
|
LLVMTypeRef param_types[1];
|
|
|
|
|
|
|
|
param_types[0] = l_ptr(StructTupleTableSlot);
|
|
|
|
|
2023-09-27 13:02:21 +02:00
|
|
|
deform_sig = LLVMFunctionType(LLVMVoidTypeInContext(lc),
|
|
|
|
param_types, lengthof(param_types), 0);
|
2018-03-26 21:57:19 +02:00
|
|
|
}
|
|
|
|
v_deform_fn = LLVMAddFunction(mod, funcname, deform_sig);
|
|
|
|
LLVMSetLinkage(v_deform_fn, LLVMInternalLinkage);
|
|
|
|
LLVMSetParamAlignment(LLVMGetParam(v_deform_fn, 0), MAXIMUM_ALIGNOF);
|
|
|
|
llvm_copy_attributes(AttributeTemplate, v_deform_fn);
|
|
|
|
|
|
|
|
b_entry =
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMAppendBasicBlockInContext(lc, v_deform_fn, "entry");
|
2018-03-26 21:57:19 +02:00
|
|
|
b_adjust_unavail_cols =
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMAppendBasicBlockInContext(lc, v_deform_fn, "adjust_unavail_cols");
|
2018-03-26 21:57:19 +02:00
|
|
|
b_find_start =
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMAppendBasicBlockInContext(lc, v_deform_fn, "find_startblock");
|
2018-03-26 21:57:19 +02:00
|
|
|
b_out =
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMAppendBasicBlockInContext(lc, v_deform_fn, "outblock");
|
2018-03-26 21:57:19 +02:00
|
|
|
b_dead =
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMAppendBasicBlockInContext(lc, v_deform_fn, "deadblock");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
2023-09-27 13:02:21 +02:00
|
|
|
b = LLVMCreateBuilderInContext(lc);
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
attcheckattnoblocks = palloc(sizeof(LLVMBasicBlockRef) * natts);
|
|
|
|
attstartblocks = palloc(sizeof(LLVMBasicBlockRef) * natts);
|
|
|
|
attisnullblocks = palloc(sizeof(LLVMBasicBlockRef) * natts);
|
|
|
|
attcheckalignblocks = palloc(sizeof(LLVMBasicBlockRef) * natts);
|
|
|
|
attalignblocks = palloc(sizeof(LLVMBasicBlockRef) * natts);
|
|
|
|
attstoreblocks = palloc(sizeof(LLVMBasicBlockRef) * natts);
|
|
|
|
|
|
|
|
known_alignment = 0;
|
|
|
|
|
|
|
|
LLVMPositionBuilderAtEnd(b, b_entry);
|
|
|
|
|
|
|
|
/* perform allocas first, llvm only converts those to registers */
|
|
|
|
v_offp = LLVMBuildAlloca(b, TypeSizeT, "v_offp");
|
|
|
|
|
|
|
|
v_slot = LLVMGetParam(v_deform_fn, 0);
|
|
|
|
|
|
|
|
v_tts_values =
|
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
|
|
|
l_load_struct_gep(b, StructTupleTableSlot, v_slot, FIELDNO_TUPLETABLESLOT_VALUES,
|
2018-03-26 21:57:19 +02:00
|
|
|
"tts_values");
|
|
|
|
v_tts_nulls =
|
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
|
|
|
l_load_struct_gep(b, StructTupleTableSlot, v_slot, FIELDNO_TUPLETABLESLOT_ISNULL,
|
2018-03-26 21:57:19 +02:00
|
|
|
"tts_ISNULL");
|
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
|
|
|
v_flagsp = l_struct_gep(b, StructTupleTableSlot, v_slot, FIELDNO_TUPLETABLESLOT_FLAGS, "");
|
|
|
|
v_nvalidp = l_struct_gep(b, StructTupleTableSlot, v_slot, FIELDNO_TUPLETABLESLOT_NVALID, "");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
Make TupleTableSlots extensible, finish split of existing slot type.
This commit completes the work prepared in 1a0586de36, splitting the
old TupleTableSlot implementation (which could store buffer, heap,
minimal and virtual slots) into four different slot types. As
described in the aforementioned commit, this is done with the goal of
making tuple table slots extensible, to allow for pluggable table
access methods.
To achieve runtime extensibility for TupleTableSlots, operations on
slots that can differ between types of slots are performed using the
TupleTableSlotOps struct provided at slot creation time. That
includes information from the size of TupleTableSlot struct to be
allocated, initialization, deforming etc. See the struct's definition
for more detailed information about callbacks TupleTableSlotOps.
I decided to rename TTSOpsBufferTuple to TTSOpsBufferHeapTuple and
ExecCopySlotTuple to ExecCopySlotHeapTuple, as that seems more
consistent with other naming introduced in recent patches.
There's plenty optimization potential in the slot implementation, but
according to benchmarking the state after this commit has similar
performance characteristics to before this set of changes, which seems
sufficient.
There's a few changes in execReplication.c that currently need to poke
through the slot abstraction, that'll be repaired once the pluggable
storage patchset provides the necessary infrastructure.
Author: Andres Freund and Ashutosh Bapat, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-17 01:35:11 +01:00
|
|
|
if (ops == &TTSOpsHeapTuple || ops == &TTSOpsBufferHeapTuple)
|
|
|
|
{
|
|
|
|
LLVMValueRef v_heapslot;
|
|
|
|
|
|
|
|
v_heapslot =
|
|
|
|
LLVMBuildBitCast(b,
|
|
|
|
v_slot,
|
|
|
|
l_ptr(StructHeapTupleTableSlot),
|
|
|
|
"heapslot");
|
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
|
|
|
v_slotoffp = l_struct_gep(b, StructHeapTupleTableSlot, v_heapslot, FIELDNO_HEAPTUPLETABLESLOT_OFF, "");
|
Make TupleTableSlots extensible, finish split of existing slot type.
This commit completes the work prepared in 1a0586de36, splitting the
old TupleTableSlot implementation (which could store buffer, heap,
minimal and virtual slots) into four different slot types. As
described in the aforementioned commit, this is done with the goal of
making tuple table slots extensible, to allow for pluggable table
access methods.
To achieve runtime extensibility for TupleTableSlots, operations on
slots that can differ between types of slots are performed using the
TupleTableSlotOps struct provided at slot creation time. That
includes information from the size of TupleTableSlot struct to be
allocated, initialization, deforming etc. See the struct's definition
for more detailed information about callbacks TupleTableSlotOps.
I decided to rename TTSOpsBufferTuple to TTSOpsBufferHeapTuple and
ExecCopySlotTuple to ExecCopySlotHeapTuple, as that seems more
consistent with other naming introduced in recent patches.
There's plenty optimization potential in the slot implementation, but
according to benchmarking the state after this commit has similar
performance characteristics to before this set of changes, which seems
sufficient.
There's a few changes in execReplication.c that currently need to poke
through the slot abstraction, that'll be repaired once the pluggable
storage patchset provides the necessary infrastructure.
Author: Andres Freund and Ashutosh Bapat, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-17 01:35:11 +01:00
|
|
|
v_tupleheaderp =
|
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
|
|
|
l_load_struct_gep(b, StructHeapTupleTableSlot, v_heapslot, FIELDNO_HEAPTUPLETABLESLOT_TUPLE,
|
Make TupleTableSlots extensible, finish split of existing slot type.
This commit completes the work prepared in 1a0586de36, splitting the
old TupleTableSlot implementation (which could store buffer, heap,
minimal and virtual slots) into four different slot types. As
described in the aforementioned commit, this is done with the goal of
making tuple table slots extensible, to allow for pluggable table
access methods.
To achieve runtime extensibility for TupleTableSlots, operations on
slots that can differ between types of slots are performed using the
TupleTableSlotOps struct provided at slot creation time. That
includes information from the size of TupleTableSlot struct to be
allocated, initialization, deforming etc. See the struct's definition
for more detailed information about callbacks TupleTableSlotOps.
I decided to rename TTSOpsBufferTuple to TTSOpsBufferHeapTuple and
ExecCopySlotTuple to ExecCopySlotHeapTuple, as that seems more
consistent with other naming introduced in recent patches.
There's plenty optimization potential in the slot implementation, but
according to benchmarking the state after this commit has similar
performance characteristics to before this set of changes, which seems
sufficient.
There's a few changes in execReplication.c that currently need to poke
through the slot abstraction, that'll be repaired once the pluggable
storage patchset provides the necessary infrastructure.
Author: Andres Freund and Ashutosh Bapat, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-17 01:35:11 +01:00
|
|
|
"tupleheader");
|
|
|
|
}
|
|
|
|
else if (ops == &TTSOpsMinimalTuple)
|
|
|
|
{
|
|
|
|
LLVMValueRef v_minimalslot;
|
|
|
|
|
|
|
|
v_minimalslot =
|
|
|
|
LLVMBuildBitCast(b,
|
|
|
|
v_slot,
|
|
|
|
l_ptr(StructMinimalTupleTableSlot),
|
2019-05-26 14:58:18 +02:00
|
|
|
"minimalslot");
|
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
|
|
|
v_slotoffp = l_struct_gep(b,
|
|
|
|
StructMinimalTupleTableSlot,
|
|
|
|
v_minimalslot,
|
|
|
|
FIELDNO_MINIMALTUPLETABLESLOT_OFF, "");
|
Make TupleTableSlots extensible, finish split of existing slot type.
This commit completes the work prepared in 1a0586de36, splitting the
old TupleTableSlot implementation (which could store buffer, heap,
minimal and virtual slots) into four different slot types. As
described in the aforementioned commit, this is done with the goal of
making tuple table slots extensible, to allow for pluggable table
access methods.
To achieve runtime extensibility for TupleTableSlots, operations on
slots that can differ between types of slots are performed using the
TupleTableSlotOps struct provided at slot creation time. That
includes information from the size of TupleTableSlot struct to be
allocated, initialization, deforming etc. See the struct's definition
for more detailed information about callbacks TupleTableSlotOps.
I decided to rename TTSOpsBufferTuple to TTSOpsBufferHeapTuple and
ExecCopySlotTuple to ExecCopySlotHeapTuple, as that seems more
consistent with other naming introduced in recent patches.
There's plenty optimization potential in the slot implementation, but
according to benchmarking the state after this commit has similar
performance characteristics to before this set of changes, which seems
sufficient.
There's a few changes in execReplication.c that currently need to poke
through the slot abstraction, that'll be repaired once the pluggable
storage patchset provides the necessary infrastructure.
Author: Andres Freund and Ashutosh Bapat, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-17 01:35:11 +01:00
|
|
|
v_tupleheaderp =
|
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
|
|
|
l_load_struct_gep(b,
|
|
|
|
StructMinimalTupleTableSlot,
|
|
|
|
v_minimalslot,
|
|
|
|
FIELDNO_MINIMALTUPLETABLESLOT_TUPLE,
|
Make TupleTableSlots extensible, finish split of existing slot type.
This commit completes the work prepared in 1a0586de36, splitting the
old TupleTableSlot implementation (which could store buffer, heap,
minimal and virtual slots) into four different slot types. As
described in the aforementioned commit, this is done with the goal of
making tuple table slots extensible, to allow for pluggable table
access methods.
To achieve runtime extensibility for TupleTableSlots, operations on
slots that can differ between types of slots are performed using the
TupleTableSlotOps struct provided at slot creation time. That
includes information from the size of TupleTableSlot struct to be
allocated, initialization, deforming etc. See the struct's definition
for more detailed information about callbacks TupleTableSlotOps.
I decided to rename TTSOpsBufferTuple to TTSOpsBufferHeapTuple and
ExecCopySlotTuple to ExecCopySlotHeapTuple, as that seems more
consistent with other naming introduced in recent patches.
There's plenty optimization potential in the slot implementation, but
according to benchmarking the state after this commit has similar
performance characteristics to before this set of changes, which seems
sufficient.
There's a few changes in execReplication.c that currently need to poke
through the slot abstraction, that'll be repaired once the pluggable
storage patchset provides the necessary infrastructure.
Author: Andres Freund and Ashutosh Bapat, with changes by Amit Khandekar
Discussion: https://postgr.es/m/20181105210039.hh4vvi4vwoq5ba2q@alap3.anarazel.de
2018-11-17 01:35:11 +01:00
|
|
|
"tupleheader");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* should've returned at the start of the function */
|
|
|
|
pg_unreachable();
|
|
|
|
}
|
|
|
|
|
2018-03-26 21:57:19 +02:00
|
|
|
v_tuplep =
|
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
|
|
|
l_load_struct_gep(b,
|
|
|
|
StructHeapTupleData,
|
|
|
|
v_tupleheaderp,
|
|
|
|
FIELDNO_HEAPTUPLEDATA_DATA,
|
2018-03-26 21:57:19 +02:00
|
|
|
"tuple");
|
|
|
|
v_bits =
|
|
|
|
LLVMBuildBitCast(b,
|
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
|
|
|
l_struct_gep(b,
|
|
|
|
StructHeapTupleHeaderData,
|
|
|
|
v_tuplep,
|
|
|
|
FIELDNO_HEAPTUPLEHEADERDATA_BITS,
|
|
|
|
""),
|
2023-09-27 13:02:21 +02:00
|
|
|
l_ptr(LLVMInt8TypeInContext(lc)),
|
2018-03-26 21:57:19 +02:00
|
|
|
"t_bits");
|
|
|
|
v_infomask1 =
|
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
|
|
|
l_load_struct_gep(b,
|
|
|
|
StructHeapTupleHeaderData,
|
|
|
|
v_tuplep,
|
2018-03-26 21:57:19 +02:00
|
|
|
FIELDNO_HEAPTUPLEHEADERDATA_INFOMASK,
|
|
|
|
"infomask1");
|
|
|
|
v_infomask2 =
|
|
|
|
l_load_struct_gep(b,
|
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
|
|
|
StructHeapTupleHeaderData,
|
2018-03-26 21:57:19 +02:00
|
|
|
v_tuplep, FIELDNO_HEAPTUPLEHEADERDATA_INFOMASK2,
|
|
|
|
"infomask2");
|
|
|
|
|
|
|
|
/* t_infomask & HEAP_HASNULL */
|
|
|
|
v_hasnulls =
|
|
|
|
LLVMBuildICmp(b, LLVMIntNE,
|
|
|
|
LLVMBuildAnd(b,
|
2023-09-27 13:02:21 +02:00
|
|
|
l_int16_const(lc, HEAP_HASNULL),
|
2018-03-26 21:57:19 +02:00
|
|
|
v_infomask1, ""),
|
2023-09-27 13:02:21 +02:00
|
|
|
l_int16_const(lc, 0),
|
2018-03-26 21:57:19 +02:00
|
|
|
"hasnulls");
|
|
|
|
|
|
|
|
/* t_infomask2 & HEAP_NATTS_MASK */
|
|
|
|
v_maxatt = LLVMBuildAnd(b,
|
2023-09-27 13:02:21 +02:00
|
|
|
l_int16_const(lc, HEAP_NATTS_MASK),
|
2018-03-26 21:57:19 +02:00
|
|
|
v_infomask2,
|
|
|
|
"maxatt");
|
|
|
|
|
2018-11-27 19:07:03 +01:00
|
|
|
/*
|
|
|
|
* Need to zext, as getelementptr otherwise treats hoff as a signed 8bit
|
|
|
|
* integer, which'd yield a negative offset for t_hoff > 127.
|
|
|
|
*/
|
2018-03-26 21:57:19 +02:00
|
|
|
v_hoff =
|
2018-11-27 19:07:03 +01:00
|
|
|
LLVMBuildZExt(b,
|
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
|
|
|
l_load_struct_gep(b,
|
|
|
|
StructHeapTupleHeaderData,
|
|
|
|
v_tuplep,
|
2018-11-27 19:07:03 +01:00
|
|
|
FIELDNO_HEAPTUPLEHEADERDATA_HOFF,
|
|
|
|
""),
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMInt32TypeInContext(lc), "t_hoff");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
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
|
|
|
v_tupdata_base = l_gep(b,
|
|
|
|
LLVMInt8TypeInContext(lc),
|
|
|
|
LLVMBuildBitCast(b,
|
|
|
|
v_tuplep,
|
|
|
|
l_ptr(LLVMInt8TypeInContext(lc)),
|
|
|
|
""),
|
|
|
|
&v_hoff, 1,
|
|
|
|
"v_tupdata_base");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Load tuple start offset from slot. Will be reset below in case there's
|
|
|
|
* no existing deformed columns in slot.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
LLVMValueRef v_off_start;
|
|
|
|
|
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
|
|
|
v_off_start = l_load(b, LLVMInt32TypeInContext(lc), v_slotoffp, "v_slot_off");
|
2018-03-26 21:57:19 +02:00
|
|
|
v_off_start = LLVMBuildZExt(b, v_off_start, TypeSizeT, "");
|
|
|
|
LLVMBuildStore(b, v_off_start, v_offp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* build the basic block for each attribute, need them as jump target */
|
|
|
|
for (attnum = 0; attnum < natts; attnum++)
|
|
|
|
{
|
|
|
|
attcheckattnoblocks[attnum] =
|
|
|
|
l_bb_append_v(v_deform_fn, "block.attr.%d.attcheckattno", attnum);
|
|
|
|
attstartblocks[attnum] =
|
|
|
|
l_bb_append_v(v_deform_fn, "block.attr.%d.start", attnum);
|
|
|
|
attisnullblocks[attnum] =
|
|
|
|
l_bb_append_v(v_deform_fn, "block.attr.%d.attisnull", attnum);
|
|
|
|
attcheckalignblocks[attnum] =
|
|
|
|
l_bb_append_v(v_deform_fn, "block.attr.%d.attcheckalign", attnum);
|
|
|
|
attalignblocks[attnum] =
|
|
|
|
l_bb_append_v(v_deform_fn, "block.attr.%d.align", attnum);
|
|
|
|
attstoreblocks[attnum] =
|
|
|
|
l_bb_append_v(v_deform_fn, "block.attr.%d.store", attnum);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2019-05-01 00:55:07 +02:00
|
|
|
* Check if it is guaranteed that all the desired attributes are available
|
|
|
|
* in the tuple (but still possibly NULL), by dint of either the last
|
|
|
|
* to-be-deformed column being NOT NULL, or subsequent ones not accessed
|
|
|
|
* here being NOT NULL. If that's not guaranteed the tuple headers natt's
|
|
|
|
* has to be checked, and missing attributes potentially have to be
|
|
|
|
* fetched (using slot_getmissingattrs().
|
2018-03-26 21:57:19 +02:00
|
|
|
*/
|
|
|
|
if ((natts - 1) <= guaranteed_column_number)
|
|
|
|
{
|
|
|
|
/* just skip through unnecessary blocks */
|
|
|
|
LLVMBuildBr(b, b_adjust_unavail_cols);
|
|
|
|
LLVMPositionBuilderAtEnd(b, b_adjust_unavail_cols);
|
|
|
|
LLVMBuildBr(b, b_find_start);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-03-28 06:03:10 +02:00
|
|
|
LLVMValueRef v_params[3];
|
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
|
|
|
LLVMValueRef f;
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
/* branch if not all columns available */
|
|
|
|
LLVMBuildCondBr(b,
|
|
|
|
LLVMBuildICmp(b, LLVMIntULT,
|
|
|
|
v_maxatt,
|
2023-09-27 13:02:21 +02:00
|
|
|
l_int16_const(lc, natts),
|
2018-03-26 21:57:19 +02:00
|
|
|
""),
|
|
|
|
b_adjust_unavail_cols,
|
|
|
|
b_find_start);
|
|
|
|
|
|
|
|
/* if not, memset tts_isnull of relevant cols to true */
|
|
|
|
LLVMPositionBuilderAtEnd(b, b_adjust_unavail_cols);
|
|
|
|
|
2018-03-28 06:03:10 +02:00
|
|
|
v_params[0] = v_slot;
|
2023-09-27 13:02:21 +02:00
|
|
|
v_params[1] = LLVMBuildZExt(b, v_maxatt, LLVMInt32TypeInContext(lc), "");
|
|
|
|
v_params[2] = l_int32_const(lc, natts);
|
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
|
|
|
f = llvm_pg_func(mod, "slot_getmissingattrs");
|
|
|
|
l_call(b,
|
|
|
|
LLVMGetFunctionType(f), f,
|
|
|
|
v_params, lengthof(v_params), "");
|
2018-03-26 21:57:19 +02:00
|
|
|
LLVMBuildBr(b, b_find_start);
|
|
|
|
}
|
|
|
|
|
|
|
|
LLVMPositionBuilderAtEnd(b, b_find_start);
|
|
|
|
|
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
|
|
|
v_nvalid = l_load(b, LLVMInt16TypeInContext(lc), v_nvalidp, "");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Build switch to go from nvalid to the right startblock. Callers
|
|
|
|
* currently don't have the knowledge, but it'd be good for performance to
|
|
|
|
* avoid this check when it's known that the slot is empty (e.g. in scan
|
|
|
|
* nodes).
|
|
|
|
*/
|
|
|
|
if (true)
|
|
|
|
{
|
|
|
|
LLVMValueRef v_switch = LLVMBuildSwitch(b, v_nvalid,
|
|
|
|
b_dead, natts);
|
|
|
|
|
|
|
|
for (attnum = 0; attnum < natts; attnum++)
|
|
|
|
{
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMValueRef v_attno = l_int16_const(lc, attnum);
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
LLVMAddCase(v_switch, v_attno, attcheckattnoblocks[attnum]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* jump from entry block to first block */
|
|
|
|
LLVMBuildBr(b, attcheckattnoblocks[0]);
|
|
|
|
}
|
|
|
|
|
|
|
|
LLVMPositionBuilderAtEnd(b, b_dead);
|
|
|
|
LLVMBuildUnreachable(b);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Iterate over each attribute that needs to be deformed, build code to
|
|
|
|
* deform it.
|
|
|
|
*/
|
|
|
|
for (attnum = 0; attnum < natts; attnum++)
|
|
|
|
{
|
|
|
|
Form_pg_attribute att = TupleDescAttr(desc, attnum);
|
|
|
|
LLVMValueRef v_incby;
|
|
|
|
int alignto;
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMValueRef l_attno = l_int16_const(lc, attnum);
|
2018-03-26 21:57:19 +02:00
|
|
|
LLVMValueRef v_attdatap;
|
|
|
|
LLVMValueRef v_resultp;
|
|
|
|
|
|
|
|
/* build block checking whether we did all the necessary attributes */
|
|
|
|
LLVMPositionBuilderAtEnd(b, attcheckattnoblocks[attnum]);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If this is the first attribute, slot->tts_nvalid was 0. Therefore
|
2019-05-01 01:13:54 +02:00
|
|
|
* also reset offset to 0, it may be from a previous execution.
|
2018-03-26 21:57:19 +02:00
|
|
|
*/
|
|
|
|
if (attnum == 0)
|
|
|
|
{
|
|
|
|
LLVMBuildStore(b, l_sizet_const(0), v_offp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Build check whether column is available (i.e. whether the tuple has
|
|
|
|
* that many columns stored). We can avoid the branch if we know
|
|
|
|
* there's a subsequent NOT NULL column.
|
|
|
|
*/
|
|
|
|
if (attnum <= guaranteed_column_number)
|
|
|
|
{
|
|
|
|
LLVMBuildBr(b, attstartblocks[attnum]);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
LLVMValueRef v_islast;
|
|
|
|
|
2018-03-28 06:03:10 +02:00
|
|
|
v_islast = LLVMBuildICmp(b, LLVMIntUGE,
|
2018-03-26 21:57:19 +02:00
|
|
|
l_attno,
|
|
|
|
v_maxatt,
|
|
|
|
"heap_natts");
|
|
|
|
LLVMBuildCondBr(b, v_islast, b_out, attstartblocks[attnum]);
|
|
|
|
}
|
|
|
|
LLVMPositionBuilderAtEnd(b, attstartblocks[attnum]);
|
|
|
|
|
2018-03-28 06:03:10 +02:00
|
|
|
/*
|
|
|
|
* Check for nulls if necessary. No need to take missing attributes
|
2019-05-01 01:13:54 +02:00
|
|
|
* into account, because if they're present the heaptuple's natts
|
2018-03-28 06:03:10 +02:00
|
|
|
* would have indicated that a slot_getmissingattrs() is needed.
|
|
|
|
*/
|
2018-03-26 21:57:19 +02:00
|
|
|
if (!att->attnotnull)
|
|
|
|
{
|
|
|
|
LLVMBasicBlockRef b_ifnotnull;
|
|
|
|
LLVMBasicBlockRef b_ifnull;
|
|
|
|
LLVMBasicBlockRef b_next;
|
|
|
|
LLVMValueRef v_attisnull;
|
|
|
|
LLVMValueRef v_nullbyteno;
|
|
|
|
LLVMValueRef v_nullbytemask;
|
|
|
|
LLVMValueRef v_nullbyte;
|
|
|
|
LLVMValueRef v_nullbit;
|
|
|
|
|
|
|
|
b_ifnotnull = attcheckalignblocks[attnum];
|
|
|
|
b_ifnull = attisnullblocks[attnum];
|
|
|
|
|
|
|
|
if (attnum + 1 == natts)
|
|
|
|
b_next = b_out;
|
|
|
|
else
|
|
|
|
b_next = attcheckattnoblocks[attnum + 1];
|
|
|
|
|
2023-09-27 13:02:21 +02:00
|
|
|
v_nullbyteno = l_int32_const(lc, attnum >> 3);
|
|
|
|
v_nullbytemask = l_int8_const(lc, 1 << ((attnum) & 0x07));
|
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
|
|
|
v_nullbyte = l_load_gep1(b, LLVMInt8TypeInContext(lc), v_bits, v_nullbyteno, "attnullbyte");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
v_nullbit = LLVMBuildICmp(b,
|
|
|
|
LLVMIntEQ,
|
|
|
|
LLVMBuildAnd(b, v_nullbyte, v_nullbytemask, ""),
|
2023-09-27 13:02:21 +02:00
|
|
|
l_int8_const(lc, 0),
|
2018-03-26 21:57:19 +02:00
|
|
|
"attisnull");
|
|
|
|
|
|
|
|
v_attisnull = LLVMBuildAnd(b, v_hasnulls, v_nullbit, "");
|
|
|
|
|
|
|
|
LLVMBuildCondBr(b, v_attisnull, b_ifnull, b_ifnotnull);
|
|
|
|
|
|
|
|
LLVMPositionBuilderAtEnd(b, b_ifnull);
|
|
|
|
|
|
|
|
/* store null-byte */
|
|
|
|
LLVMBuildStore(b,
|
2023-09-27 13:02:21 +02:00
|
|
|
l_int8_const(lc, 1),
|
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
|
|
|
l_gep(b, LLVMInt8TypeInContext(lc), v_tts_nulls, &l_attno, 1, ""));
|
2018-03-26 21:57:19 +02:00
|
|
|
/* store zero datum */
|
|
|
|
LLVMBuildStore(b,
|
|
|
|
l_sizet_const(0),
|
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
|
|
|
l_gep(b, TypeSizeT, v_tts_values, &l_attno, 1, ""));
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
LLVMBuildBr(b, b_next);
|
|
|
|
attguaranteedalign = false;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* nothing to do */
|
|
|
|
LLVMBuildBr(b, attcheckalignblocks[attnum]);
|
|
|
|
LLVMPositionBuilderAtEnd(b, attisnullblocks[attnum]);
|
|
|
|
LLVMBuildBr(b, attcheckalignblocks[attnum]);
|
|
|
|
}
|
|
|
|
LLVMPositionBuilderAtEnd(b, attcheckalignblocks[attnum]);
|
|
|
|
|
|
|
|
/* determine required alignment */
|
2020-03-04 16:34:25 +01:00
|
|
|
if (att->attalign == TYPALIGN_INT)
|
2018-03-26 21:57:19 +02:00
|
|
|
alignto = ALIGNOF_INT;
|
2020-03-04 16:34:25 +01:00
|
|
|
else if (att->attalign == TYPALIGN_CHAR)
|
2018-03-26 21:57:19 +02:00
|
|
|
alignto = 1;
|
2020-03-04 16:34:25 +01:00
|
|
|
else if (att->attalign == TYPALIGN_DOUBLE)
|
2018-03-26 21:57:19 +02:00
|
|
|
alignto = ALIGNOF_DOUBLE;
|
2020-03-04 16:34:25 +01:00
|
|
|
else if (att->attalign == TYPALIGN_SHORT)
|
2018-03-26 21:57:19 +02:00
|
|
|
alignto = ALIGNOF_SHORT;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
elog(ERROR, "unknown alignment");
|
|
|
|
alignto = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ------
|
|
|
|
* Even if alignment is required, we can skip doing it if provably
|
|
|
|
* unnecessary:
|
|
|
|
* - first column is guaranteed to be aligned
|
|
|
|
* - columns following a NOT NULL fixed width datum have known
|
|
|
|
* alignment, can skip alignment computation if that known alignment
|
|
|
|
* is compatible with current column.
|
|
|
|
* ------
|
|
|
|
*/
|
|
|
|
if (alignto > 1 &&
|
|
|
|
(known_alignment < 0 || known_alignment != TYPEALIGN(alignto, known_alignment)))
|
|
|
|
{
|
|
|
|
/*
|
2019-05-01 01:13:54 +02:00
|
|
|
* When accessing a varlena field, we have to "peek" to see if we
|
2018-03-26 21:57:19 +02:00
|
|
|
* are looking at a pad byte or the first byte of a 1-byte-header
|
|
|
|
* datum. A zero byte must be either a pad byte, or the first
|
2019-05-01 01:13:54 +02:00
|
|
|
* byte of a correctly aligned 4-byte length word; in either case,
|
2018-03-26 21:57:19 +02:00
|
|
|
* we can align safely. A non-zero byte must be either a 1-byte
|
|
|
|
* length word, or the first byte of a correctly aligned 4-byte
|
2019-05-01 01:13:54 +02:00
|
|
|
* length word; in either case, we need not align.
|
2018-03-26 21:57:19 +02:00
|
|
|
*/
|
|
|
|
if (att->attlen == -1)
|
|
|
|
{
|
|
|
|
LLVMValueRef v_possible_padbyte;
|
|
|
|
LLVMValueRef v_ispad;
|
|
|
|
LLVMValueRef v_off;
|
|
|
|
|
|
|
|
/* don't know if short varlena or not */
|
|
|
|
attguaranteedalign = false;
|
|
|
|
|
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
|
|
|
v_off = l_load(b, TypeSizeT, v_offp, "");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
v_possible_padbyte =
|
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
|
|
|
l_load_gep1(b, LLVMInt8TypeInContext(lc), v_tupdata_base, v_off, "padbyte");
|
2018-03-26 21:57:19 +02:00
|
|
|
v_ispad =
|
|
|
|
LLVMBuildICmp(b, LLVMIntEQ,
|
2023-09-27 13:02:21 +02:00
|
|
|
v_possible_padbyte, l_int8_const(lc, 0),
|
2018-03-26 21:57:19 +02:00
|
|
|
"ispadbyte");
|
|
|
|
LLVMBuildCondBr(b, v_ispad,
|
|
|
|
attalignblocks[attnum],
|
|
|
|
attstoreblocks[attnum]);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
LLVMBuildBr(b, attalignblocks[attnum]);
|
|
|
|
}
|
|
|
|
|
|
|
|
LLVMPositionBuilderAtEnd(b, attalignblocks[attnum]);
|
|
|
|
|
|
|
|
/* translation of alignment code (cf TYPEALIGN()) */
|
|
|
|
{
|
|
|
|
LLVMValueRef v_off_aligned;
|
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
|
|
|
LLVMValueRef v_off = l_load(b, TypeSizeT, v_offp, "");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
/* ((ALIGNVAL) - 1) */
|
|
|
|
LLVMValueRef v_alignval = l_sizet_const(alignto - 1);
|
|
|
|
|
|
|
|
/* ((uintptr_t) (LEN) + ((ALIGNVAL) - 1)) */
|
|
|
|
LLVMValueRef v_lh = LLVMBuildAdd(b, v_off, v_alignval, "");
|
|
|
|
|
|
|
|
/* ~((uintptr_t) ((ALIGNVAL) - 1)) */
|
|
|
|
LLVMValueRef v_rh = l_sizet_const(~(alignto - 1));
|
|
|
|
|
|
|
|
v_off_aligned = LLVMBuildAnd(b, v_lh, v_rh, "aligned_offset");
|
|
|
|
|
|
|
|
LLVMBuildStore(b, v_off_aligned, v_offp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* As alignment either was unnecessary or has been performed, we
|
|
|
|
* now know the current alignment. This is only safe because this
|
|
|
|
* value isn't used for varlena and nullable columns.
|
|
|
|
*/
|
|
|
|
if (known_alignment >= 0)
|
|
|
|
{
|
|
|
|
Assert(known_alignment != 0);
|
|
|
|
known_alignment = TYPEALIGN(alignto, known_alignment);
|
|
|
|
}
|
|
|
|
|
|
|
|
LLVMBuildBr(b, attstoreblocks[attnum]);
|
|
|
|
LLVMPositionBuilderAtEnd(b, attstoreblocks[attnum]);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
LLVMPositionBuilderAtEnd(b, attcheckalignblocks[attnum]);
|
|
|
|
LLVMBuildBr(b, attalignblocks[attnum]);
|
|
|
|
LLVMPositionBuilderAtEnd(b, attalignblocks[attnum]);
|
|
|
|
LLVMBuildBr(b, attstoreblocks[attnum]);
|
|
|
|
}
|
|
|
|
LLVMPositionBuilderAtEnd(b, attstoreblocks[attnum]);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Store the current offset if known to be constant. That allows LLVM
|
|
|
|
* to generate better code. Without that LLVM can't figure out that
|
|
|
|
* the offset might be constant due to the jumps for previously
|
|
|
|
* decoded columns.
|
|
|
|
*/
|
|
|
|
if (attguaranteedalign)
|
|
|
|
{
|
|
|
|
Assert(known_alignment >= 0);
|
|
|
|
LLVMBuildStore(b, l_sizet_const(known_alignment), v_offp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* compute what following columns are aligned to */
|
|
|
|
if (att->attlen < 0)
|
|
|
|
{
|
|
|
|
/* can't guarantee any alignment after variable length field */
|
|
|
|
known_alignment = -1;
|
|
|
|
attguaranteedalign = false;
|
|
|
|
}
|
|
|
|
else if (att->attnotnull && attguaranteedalign && known_alignment >= 0)
|
|
|
|
{
|
|
|
|
/*
|
2019-05-01 01:13:54 +02:00
|
|
|
* If the offset to the column was previously known, a NOT NULL &
|
|
|
|
* fixed-width column guarantees that alignment is just the
|
2018-03-26 21:57:19 +02:00
|
|
|
* previous alignment plus column width.
|
|
|
|
*/
|
|
|
|
Assert(att->attlen > 0);
|
|
|
|
known_alignment += att->attlen;
|
|
|
|
}
|
|
|
|
else if (att->attnotnull && (att->attlen % alignto) == 0)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* After a NOT NULL fixed-width column with a length that is a
|
|
|
|
* multiple of its alignment requirement, we know the following
|
|
|
|
* column is aligned to at least the current column's alignment.
|
|
|
|
*/
|
|
|
|
Assert(att->attlen > 0);
|
|
|
|
known_alignment = alignto;
|
|
|
|
Assert(known_alignment > 0);
|
|
|
|
attguaranteedalign = false;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
known_alignment = -1;
|
|
|
|
attguaranteedalign = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* compute address to load data from */
|
|
|
|
{
|
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
|
|
|
LLVMValueRef v_off = l_load(b, TypeSizeT, v_offp, "");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
v_attdatap =
|
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
|
|
|
l_gep(b, LLVMInt8TypeInContext(lc), v_tupdata_base, &v_off, 1, "");
|
2018-03-26 21:57:19 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* compute address to store value at */
|
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
|
|
|
v_resultp = l_gep(b, TypeSizeT, v_tts_values, &l_attno, 1, "");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
/* store null-byte (false) */
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMBuildStore(b, l_int8_const(lc, 0),
|
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
|
|
|
l_gep(b, TypeStorageBool, v_tts_nulls, &l_attno, 1, ""));
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
/*
|
2019-05-01 01:13:54 +02:00
|
|
|
* Store datum. For byval: datums copy the value, extend to Datum's
|
|
|
|
* width, and store. For byref types: store pointer to data.
|
2018-03-26 21:57:19 +02:00
|
|
|
*/
|
|
|
|
if (att->attbyval)
|
|
|
|
{
|
|
|
|
LLVMValueRef v_tmp_loaddata;
|
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
|
|
|
LLVMTypeRef vartype = LLVMIntTypeInContext(lc, att->attlen * 8);
|
|
|
|
LLVMTypeRef vartypep = LLVMPointerType(vartype, 0);
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
v_tmp_loaddata =
|
|
|
|
LLVMBuildPointerCast(b, v_attdatap, vartypep, "");
|
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
|
|
|
v_tmp_loaddata = l_load(b, vartype, v_tmp_loaddata, "attr_byval");
|
2018-03-26 21:57:19 +02:00
|
|
|
v_tmp_loaddata = LLVMBuildZExt(b, v_tmp_loaddata, TypeSizeT, "");
|
|
|
|
|
|
|
|
LLVMBuildStore(b, v_tmp_loaddata, v_resultp);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
LLVMValueRef v_tmp_loaddata;
|
|
|
|
|
|
|
|
/* store pointer */
|
|
|
|
v_tmp_loaddata =
|
|
|
|
LLVMBuildPtrToInt(b,
|
|
|
|
v_attdatap,
|
|
|
|
TypeSizeT,
|
|
|
|
"attr_ptr");
|
|
|
|
LLVMBuildStore(b, v_tmp_loaddata, v_resultp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* increment data pointer */
|
|
|
|
if (att->attlen > 0)
|
|
|
|
{
|
|
|
|
v_incby = l_sizet_const(att->attlen);
|
|
|
|
}
|
|
|
|
else if (att->attlen == -1)
|
|
|
|
{
|
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
|
|
|
v_incby = l_call(b,
|
|
|
|
llvm_pg_var_func_type("varsize_any"),
|
|
|
|
llvm_pg_func(mod, "varsize_any"),
|
|
|
|
&v_attdatap, 1,
|
|
|
|
"varsize_any");
|
2018-03-26 21:57:19 +02:00
|
|
|
l_callsite_ro(v_incby);
|
|
|
|
l_callsite_alwaysinline(v_incby);
|
|
|
|
}
|
|
|
|
else if (att->attlen == -2)
|
|
|
|
{
|
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
|
|
|
v_incby = l_call(b,
|
|
|
|
llvm_pg_var_func_type("strlen"),
|
|
|
|
llvm_pg_func(mod, "strlen"),
|
|
|
|
&v_attdatap, 1, "strlen");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
l_callsite_ro(v_incby);
|
|
|
|
|
|
|
|
/* add 1 for NUL byte */
|
|
|
|
v_incby = LLVMBuildAdd(b, v_incby, l_sizet_const(1), "");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
Assert(false);
|
|
|
|
v_incby = NULL; /* silence compiler */
|
|
|
|
}
|
|
|
|
|
|
|
|
if (attguaranteedalign)
|
|
|
|
{
|
|
|
|
Assert(known_alignment >= 0);
|
|
|
|
LLVMBuildStore(b, l_sizet_const(known_alignment), v_offp);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
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
|
|
|
LLVMValueRef v_off = l_load(b, TypeSizeT, v_offp, "");
|
2018-03-26 21:57:19 +02:00
|
|
|
|
|
|
|
v_off = LLVMBuildAdd(b, v_off, v_incby, "increment_offset");
|
|
|
|
LLVMBuildStore(b, v_off, v_offp);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* jump to next block, unless last possible column, or all desired
|
|
|
|
* (available) attributes have been fetched.
|
|
|
|
*/
|
|
|
|
if (attnum + 1 == natts)
|
|
|
|
{
|
|
|
|
/* jump out */
|
|
|
|
LLVMBuildBr(b, b_out);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
LLVMBuildBr(b, attcheckattnoblocks[attnum + 1]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* build block that returns */
|
|
|
|
LLVMPositionBuilderAtEnd(b, b_out);
|
|
|
|
|
|
|
|
{
|
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
|
|
|
LLVMValueRef v_off = l_load(b, TypeSizeT, v_offp, "");
|
2018-10-16 00:24:33 +02:00
|
|
|
LLVMValueRef v_flags;
|
2018-03-26 21:57:19 +02:00
|
|
|
|
2023-09-27 13:02:21 +02:00
|
|
|
LLVMBuildStore(b, l_int16_const(lc, natts), v_nvalidp);
|
|
|
|
v_off = LLVMBuildTrunc(b, v_off, LLVMInt32TypeInContext(lc), "");
|
2018-03-26 21:57:19 +02:00
|
|
|
LLVMBuildStore(b, v_off, v_slotoffp);
|
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
|
|
|
v_flags = l_load(b, LLVMInt16TypeInContext(lc), v_flagsp, "tts_flags");
|
2023-09-27 13:02:21 +02:00
|
|
|
v_flags = LLVMBuildOr(b, v_flags, l_int16_const(lc, TTS_FLAG_SLOW), "");
|
2018-10-16 00:24:33 +02:00
|
|
|
LLVMBuildStore(b, v_flags, v_flagsp);
|
2018-03-26 21:57:19 +02:00
|
|
|
LLVMBuildRetVoid(b);
|
|
|
|
}
|
|
|
|
|
|
|
|
LLVMDisposeBuilder(b);
|
|
|
|
|
|
|
|
return v_deform_fn;
|
|
|
|
}
|