History log of /freebsd/sys/sys/tree.h (Results 1 – 25 of 350)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: vendor/llvm-project/llvmorg-18.1.5-0-g617a15a9eac9, vendor/NetBSD/bmake/20240430, vendor/libcbor/0.11.0, vendor/llvm-project/llvmorg-18.1.4-0-ge6c3289804a6, vendor/device-tree/6.8, vendor/device-tree/6.7, vendor/llvm-project/llvmorg-18.1.3-0-gc13b7485b879, vendor/device-tree/6.5, vendor/openssh/9.7p1, vendor/unbound/1.19.3, vendor/NetBSD/bmake/20240309, vendor/sqlite3/sqlite-3450100, vendor/llvm-project/llvmorg-18.1.1-0-gdba2a75e9c7e, vendor/got/diff/2023-09-15, release/13.3.0, vendor/libucl/20240206, vendor/xz/5.6.0, vendor/llvm-project/llvmorg-18.1.0-rc3-0-g6c90f8dd5463, vendor/llvm-project/llvmorg-18.1.0-rc2-53-gc7b0a6ecd442, vendor/arm-optimized-routines/v24.01, vendor/zlib/1.3.1, vendor/expat/2.6.0, vendor/unbound/1.19.1, vendor/tzcode/tzcode2024a, vendor/llvm-project/llvmorg-18.1.0-rc2-0-gc6c86965d967, vendor/tzdata/tzdata2024a, vendor/sendmail/8.18.1, vendor/acpica/20230628, vendor/acpica/20230331, vendor/llvm-project/llvmorg-18-init-18361-g22683463740e, vendor/libcxxrt/2024-01-25-fd484be8d1e94a1fcf6bc5c67e5c07b65ada19b6, vendor/llvm-project/llvmorg-18-init-18359-g93248729cfae, vendor/sqlite3/sqlite-3450000, vendor/NetBSD/bmake/20240108, vendor/llvm-project/llvmorg-18-init-16864-g3b3ee1f53424, vendor/llvm-project/llvmorg-18-init-16595-g7c00a5be5cde, vendor/llvm-project/llvmorg-18-init-16003-gfc5f51cf5af4, vendor/bc/6.7.4, vendor/ena-com/2.7.0, vendor/llvm-project/llvmorg-18-init-15692-g007ed0dccd6a, vendor/tzdata/tzdata2023d, vendor/openssh/9.6p1, vendor/llvm-project/llvmorg-18-init-15088-gd14ee76181fb, vendor/llvm-project/llvmorg-18-init-14265-ga17671084db1, vendor/llvm-project/llvmorg-17.0.6-0-g6009708b4367, vendor/xz/5.4.5, vendor/llvm-project/llvmorg-17.0.5-0-g98bfdac5ce82, vendor/unbound/1.19.0, vendor/sqlite3/sqlite-3440000, release/14.0.0, vendor/bc/6.7.2, vendor/llvm-project/llvmorg-17.0.3-0-g888437e1b600, vendor/bsddialog/1.0, vendor/llvm-project/llvmorg-17.0.2-0-gb2417f51dbbd, vendor/openssh/9.5p1, vendor/llvm-project/llvmorg-17.0.1-25-g098e653a5bed, vendor/nvi/2.2.1, vendor/openssl/3.0.11, vendor/sqlite3/sqlite-3430100, vendor/unbound/1.18.0, vendor/NetBSD/bmake/20230909, vendor/openssl/1.1.1w, vendor/llvm-project/llvmorg-17.0.0-rc4-10-g0176e8729ea4, vendor/file/5.45, vendor/llvm-project/llvmorg-17.0.0-rc3-79-ga612cb0b81d8, vendor/krb5/1.21.2, vendor/unifdef/2.12, vendor/unifdef/2.11, 2023.08.19-b34f66deb02e188104, vendor/zlib/1.3
# 71625ec9 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c comment pattern

Remove /^/[*/]\s*\$FreeBSD\$.*\n/


Revision tags: vendor/less/v643, vendor/NetBSD/libc-vis/20230813, vendor/openssh/9.4p1, vendor/device-tree/6.4, vendor/device-tree/6.3, vendor/device-tree/6.2, vendor/device-tree/6.1, vendor/krb5/1.21.1, vendor/xz/5.4.4, vendor/openssl/3.0.10, vendor/openssl/1.1.1v, vendor/llvm-project/llvmorg-17-init-19311-gbc849e525f80, vendor/llvm-project/llvmorg-17-init-19304-gd0b54bb50e51, vendor/openssh/9.3p2, vendor/lua/5.4.6, vendor/NetBSD/bmake/20230622, vendor/openpam/XIMENIA, vendor/heimdal/7.8.0-2023-06-10-f62e2f278, vendor/openssl/3.0.9, vendor/llvm-project/llvmorg-16.0.6-0-g7cbf1a259152, vendor/ntp/4.2.8p17, vendor/llvm-project/llvmorg-16.0.5-0-g185b81e034ba, vendor/spleen/2.0.0, vendor/ntp/4.2.8p16, vendor/openssl/1.1.1u, vendor/sqlite3/sqlite-3420000, vendor/bc/6.6.0, vendor/llvm-project/llvmorg-16.0.4-0-gae42196bc493, vendor/NetBSD/bmake/20230510, vendor/xz/5.4.3
# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...


Revision tags: vendor/tcpdump/4.99.4, vendor/llvm-project/llvmorg-16.0.3-0-gda3cd333bea5, vendor/ldns/1.8.3, vendor/spleen/1.9.3, vendor/libpcap/1.10.4, vendor/spleen/1.6.0, vendor/less/v632, vendor/bc/6.5.0, vendor/libfido2/1.13.0, vendor/libfido2/1.12.0, vendor/libfido2/1.11.0, vendor/libfido2/1.10.0, vendor/libfido2/1.9.0, vendor/NetBSD/bmake/20230414, vendor/llvm-project/llvmorg-16.0.2-0-g18ddebe1a1a9, vendor/libcbor/0.10.2, vendor/tzcode/tzcode2023c, vendor/tzcode/tzcode2023b, vendor/tzcode/tzcode2023a, vendor/sqlite3/sqlite-3410200, vendor/llvm-project/llvmorg-16.0.1-0-gcd89023f7979, release/13.2.0, vendor/llvm-project/llvmorg-16.0.0-45-g42d1b276f779, vendor/llvm-project/llvmorg-16.0.0-0-g08d094a0e457, vendor/tzdata/tzdata2023c, vendor/libpcap/1.10.3, vendor/opencsd/v1.4.0, vendor/arm-optimized-routines/v23.01, vendor/tzdata/tzdata2023b, vendor/tzdata/tzdata2023a, vendor/xz/5.4.2, vendor/openssh/9.3p1, vendor/openssl/3.0.8, vendor/bc/6.4.0, vendor/sqlite3/sqlite-3410000, vendor/bc/6.3.1, vendor/bearssl/20230220, vendor/zlib/1.2.13, vendor/llvm-project/llvmorg-16.0.0-rc2-10-g073506d8c15c, vendor/llvm-project/llvmorg-16-init-18548-gb0daacf58f41, vendor/NetBSD/bmake/20230208, vendor/byacc/20230201, vendor/openssl/1.1.1t, vendor/NetBSD/libedit/2023-01-06, vendor/openssh/9.2p1, vendor/tcsh/6.24.07, vendor/bc/6.2.2, vendor/bc/6.2.1, vendor/bc/6.2.0, vendor/bc/6.1.0, vendor/bc/6.0.4, vendor/NetBSD/bmake/20230126, vendor/Juniper/libxo/1.6.0, vendor/zstd/1.5.2, vendor/xz/5.4.1, vendor/sendmail/8.17.1, vendor/llvm-project/llvmorg-15.0.7-0-g8dfdcc7b7bf6, vendor/heimdal/7.8.0, vendor/sqlite3/sqlite-3400100, vendor/xz/5.4.0, vendor/tzcode/tzcode2022g, vendor/tzcode/tzcode2022f, vendor/tzcode/tzcode2022e, vendor/tzcode/tzcode2022d, vendor/xz/5.2.9
# c2ddf2ed 05-Dec-2022 Poul-Henning Kamp <phk@FreeBSD.org>

tree.h: Fix SP/TAB white-space issues, add () for clarity.


Revision tags: vendor/llvm-project/llvmorg-15.0.6-0-g088f33605d8a, vendor/tzdata/tzdata2022g, release/12.4.0, vendor/sqlite3/sqlite-3400000, vendor/expat/2.5.0, vendor/xz/5.2.8, vendor/device-tree/6.0, vendor/device-tree/5.19, vendor/openssl/1.1.1s, vendor/wireguard-tools/v1.0.20210914, vendor/tzdata/tzdata2022f, vendor/acpica/20221020, vendor/unbound/1.17.0, vendor/llvm-project/llvmorg-15.0.2-10-gf3c5289e7846, vendor/llvm-project/llvmorg-15.0.2-0-g4bd3f3759259, vendor/llvm-project/llvmorg-15.0.1-0-gb73d2c8c720a, vendor/tzdata/tzdata2022e, vendor/openssh/9.1p1
# ffbc2a58 03-Oct-2022 Doug Moore <dougm@FreeBSD.org>

Fix LINT build after 368ee2f86a0f4f6
Reported by: jenkins
Fixes: 368ee2f86a0f4f6


# 368ee2f8 03-Oct-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: let insert search start from next node

When the node to insert in the rb_tree is known to precede or follow a
particular node, new methods RB_INSERT_PREV and RB_INSERT_NEXT,
defined here, a

rb_tree: let insert search start from next node

When the node to insert in the rb_tree is known to precede or follow a
particular node, new methods RB_INSERT_PREV and RB_INSERT_NEXT,
defined here, allow the search for where to insert the new node begin
with that particular node, rather than at the root, to save a bit of
time.

Using those methods, instead of RB_INSERT, in managing a tree in
iommu_gas.c, saves a little time.

Reviewed by: kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D35516

show more ...


# 1aef5711 29-Sep-2022 John Baldwin <jhb@FreeBSD.org>

rb_tree: Use void casts for RB_AUGMENT_CHECK with unused return value.

Reviewed by: dougm
Reported by: GCC -Wunused-value
Differential Revision: https://reviews.freebsd.org/D36778


Revision tags: vendor/unbound/1.16.3
# b5b07c71 26-Sep-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: add augmentation comments

Add comments to better explain why augmentation is done in several places.
Reviewed by: alc
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D

rb_tree: add augmentation comments

Add comments to better explain why augmentation is done in several places.
Reviewed by: alc
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36646

show more ...


Revision tags: vendor/bsddialog/0.4, vendor/tzdata/tzdata2022d, vendor/file/5.43, vendor/expat/2.4.9
# 86d00db4 21-Sep-2022 Doug Moore <dougm@FreeBSD.org>

Use 0 and 1, not false and true, in tree.h changes.
Reported by: jenkins


# b16f993e 21-Sep-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: augmentation shortcut

RB-tree augmentation maintains data in each node of the tree that
represents the product of some associative operator applied to all the
nodes of the subtree rooted at

rb_tree: augmentation shortcut

RB-tree augmentation maintains data in each node of the tree that
represents the product of some associative operator applied to all the
nodes of the subtree rooted at that node. If a node in the tree
changes, augmentation data for the node is updated for that node and
all nodes on the path from that node to the tree root. However,
sometimes, augmenting a node changes no data in that node,
particularly if the associated operation is something involving 'max'
or 'min'. If augmentation changes nothing in a node, then the work of
walking to the tree root from that point is pointless, because
augmentation will change nothing in those nodes either. This change
makes it possible to avoid that wasted work.

Define RB_AUGMENT_CHECK as a macro much like RB_AUGMENT, but which
returns a value 'true' when augmentation changes the augmentation data
of a node, and false otherwise. Change code that unconditionally walks
and augments to the top of tree to code that stops once an
augmentation has no effect. In the case of rebalancing the tree after
insertion or deletion, where previously a node rotated into the path
was inevitably augmented on the march to the tree root, now check to
see if it needs augmentation because the march to the tree root
stopped before reaching it.

Change the augmentation function in iommu_gas.c so that it returns
true/false to indicate whether the augmentation had any effect.

Reviewed by: alc, kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D36509

show more ...


Revision tags: vendor/sqlite3/sqlite-3390300
# 14696d81 18-Sep-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: silence unused function warnings

With DIAGNOSTIC set a kernel build generates warnings about the
defined-but-unused RB_RANK method. Don't set _RB_DIAGNOSTIC
automatically, to silence these

rb_tree: silence unused function warnings

With DIAGNOSTIC set a kernel build generates warnings about the
defined-but-unused RB_RANK method. Don't set _RB_DIAGNOSTIC
automatically, to silence these warnings.

Reported by: mjguzik@gmail.com
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D36617

show more ...


# 4893472c 13-Sep-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: pass parent to RB_INSERT_COLOR

Change RB_COLOR_INSERT to take a parent parameter, to avoid looking up
a value already available. Make adjustments to a linux rbtree header,
which invokes it.

rb_tree: pass parent to RB_INSERT_COLOR

Change RB_COLOR_INSERT to take a parent parameter, to avoid looking up
a value already available. Make adjustments to a linux rbtree header,
which invokes it.

Reviewed by: alc, hselasky
Differential Revision: https://reviews.freebsd.org/D36114

show more ...


Revision tags: vendor/llvm-project/llvmorg-15.0.0-9-g1c73596d3454, vendor/llvm-project/llvmorg-15.0.0-0-g4ba6a9c9f65b
# d0354fa7 08-Sep-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: reduce duplication in balancing code

Change RB_INSERT_COLOR and RB_REMOVE_COLOR so that the blocks of code
that are identical except for left and right being exchanged are made
only one blo

rb_tree: reduce duplication in balancing code

Change RB_INSERT_COLOR and RB_REMOVE_COLOR so that the blocks of code
that are identical except for left and right being exchanged are made
only one block with a variable to indicate left- or right-handedness.

Rename RB macros so that those not intended for external use begin
with an underscore.

Add comments to the balancing code so that another might understand it.

Reviewed by: alc, kib
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D36393

show more ...


# 2c545cf3 08-Sep-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: test rank balance

With _RB_DIAGNOSTIC defined, provide an RB_RANK method to compute the
rank of a node in an rb-tree, if the subtree rooted at that node is
rank-balanced, and -1 otherwise.

rb_tree: test rank balance

With _RB_DIAGNOSTIC defined, provide an RB_RANK method to compute the
rank of a node in an rb-tree, if the subtree rooted at that node is
rank-balanced, and -1 otherwise.

In rb_test, rewrite a bit to avoid malloc/free and nondeterministic
running times because of randomness. Allocate all the nodes on the
stack, and shuffle a set of keys to get randomness for the testing.

Add a rank-balance check for the completed tree.

Reviewed by: markj
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D36484

show more ...


Revision tags: vendor/less/v608, vendor/bsddialog/0.3, vendor/lua/5.4.4, vendor/lua/5.4.3, vendor/sqlite3/sqlite-3390200, vendor/bc/6.0.2, verndor/bc/6.0.2
# 5d913868 29-Aug-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: avoid extra reads in rebalancing

In RB_INSERT_COLOR and RB_REMOVE_COLOR, avoid reading a parent pointer
from memory, and then reading the left-color bit from memory, and then
reading the ri

rb_tree: avoid extra reads in rebalancing

In RB_INSERT_COLOR and RB_REMOVE_COLOR, avoid reading a parent pointer
from memory, and then reading the left-color bit from memory, and then
reading the right-color bit from memory, since they're all in the same
field. The compiler can't infer that only the first read is really
necessary, so write the code in a way so that it doesn't have to.

Drop RB_RED_LEFT and RB_RED_RIGHT macros that reach into memory to get
those bits. Drop RB_COLOR, the only thing left using RB_RED_LEFT and
RB_RED_RIGHT after the other changes, and go straight to DIAGNOSTIC
code in subr_stats to implement RB_COLOR for its single, dubious use
there.

Reviewed by: alc
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D36353

show more ...


Revision tags: vendor/dhcpcd/9.4.1
# 5886089e 28-Aug-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: fine-tune RB_REMOVE

Improve RB_REMOVE by reading the fields of the removed node only once,
and by not writing to the removed node.

Reviewed by: kib
Discussed with: markj
MFC after: 3 weeks

rb_tree: fine-tune RB_REMOVE

Improve RB_REMOVE by reading the fields of the removed node only once,
and by not writing to the removed node.

Reviewed by: kib
Discussed with: markj
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D36288

show more ...


# b6ce129d 25-Aug-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: optimize rb_insert

In searching for where to insert a new node, RB_INSERT discards the
address of the pointer that will have to be modified, so that it must
find it again from the values of

rb_tree: optimize rb_insert

In searching for where to insert a new node, RB_INSERT discards the
address of the pointer that will have to be modified, so that it must
find it again from the values of 'parent' and 'comp'. Stop discarding
that address, and so avoid having to recompute it.

Reviewed by: alc
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D36317

show more ...


# 02d0c43c 19-Aug-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: speed-up double rotation

RB_ROTATE_LEFT (and it symmetric twin) modify the rb-tree, adjusting
pointers so that what started as a proper tree ends up a proper
tree. When two consecutive rota

rb_tree: speed-up double rotation

RB_ROTATE_LEFT (and it symmetric twin) modify the rb-tree, adjusting
pointers so that what started as a proper tree ends up a proper
tree. When two consecutive rotations move the same node up the tree,
some of the pointers changed in the first rotation are immediately
changed again in the second - namely, the pointer from the rising node
to its new parent, and the pointer from that parent back to the rising
node. This change removes from RB_ROTATE macros the responsibility for
managing those two pointers, and leaves it to the code that calls for
rotations to fix up those pointers afterward. That drops a comparison
and a pair of assignments from every INSERT_COLOR or REMOVE_COLOR call
that ends in a double rotation.

A side-effect of this change is that the SWAP_CHILD macro must take as
a parameter a pointer to the node that is changing children, where it
is now computed from the old child. Since this macro is called in a
couple of places besides the RB_ROTATE macros, those calls are also
affected.

Reviewed by: alc
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D36266

show more ...


Revision tags: vendor/tzcode/tzcode2022c, vendor/tzcode/unsplit, vendor/tzdata/tzdata2022c, vendor/llvm-project/llvmorg-15.0.0-rc2-40-gfbd2950d8d0d, vendor/tzdata/tzdata2022b, vendor/arm-optimized-routines/20220210-89ca9c3, vendor/device-tree/5.18, vendor/device-tree/5.17, vendor/device-tree/5.16, vendor/device-tree/5.15, vendor/device-tree/5.14
# 7f2ec173 06-Aug-2022 Doug Moore <dougm@FreeBSD.org>

iommu_gas: avoid pointless augmentation

iommu_gas_augment_entry updates a map entry element. Invoked as
RB_AUGMENT in RB tree code, it is applied from the point where the
tree is modified, all the w

iommu_gas: avoid pointless augmentation

iommu_gas_augment_entry updates a map entry element. Invoked as
RB_AUGMENT in RB tree code, it is applied from the point where the
tree is modified, all the way up to the root, and is also applied when
rotation moves a node down in the tree.

There are several opportunities to invoke it less. The automatic
augmentation with every rotation is a mistake. Delaying these
augmentations until RB_INSERT_COLOR or RB_REMOVE_COLOR are finishing
allows the augmentation code to be duplicated less, to work when there
is less register pressure, and to be skipped when conditions allow it:

In the double-rotate case of RB_INSERT_COLOR, augmentation after
the first rotation is not necessary when the element being moved
down the tree becomes a leaf. It was in the tree, and was a leaf,
before the RB_INSERT operation began, and so recomputing
augmentation for it would do nothing.

In the final (possibly only) rotation of RB_REMOVE_COLOR, both the
elements - the one moving up and the one moving down - end up in
the path from the deletion point to the tree root, so there's no
need to augment either of them immediately.

In RB_REMOVE, when the right child of the removed node replaces it
in tree, it began with a null left child. Replacement creates a
non-NULL left child, and then rotation may put a NULL node back in
that place. If that happens, start the augmenting-up-to-root with
the parent of that node, since augmentation would do nothing.

Adjust to avoid these needless augmentations.

Reviewed by: alc
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D35502

show more ...


Revision tags: vendor/unbound/1.16.2
# b3fd5464 02-Aug-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: resolve name clash

Rename 'tmp' to 'rb_update_tmp' in a macro to avoid a shadow variable panic.

Reported by: imb@protected-networks.net
Fixes: 35557a0d9169


# 35557a0d 02-Aug-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: update augmentation after element change

For an augmented rb_tree, allow a faster alternative to removing an
element from the tree, tweaking it slightly, and inserting it back
into the tree

rb_tree: update augmentation after element change

For an augmented rb_tree, allow a faster alternative to removing an
element from the tree, tweaking it slightly, and inserting it back
into the tree, knowing that its relative position in the tree is
unchanged. Instead, just change the element and invoke
RB_UPDATE_AUGMENT to fix the augmentation data for all the nodes in
the tree.

Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D36010

show more ...


Revision tags: vendor/llvm-project/llvmorg-15-init-17826-g1f8ae9d7e7e4, vendor/llvm-project/llvmorg-15-init-17827-gd77882e66779, vendor/NetBSD/bmake/20220726, vendor/NetBSD/bmake/20220724, vendor/llvm-project/llvmorg-15-init-17485-ga3e38b4a206b, vendor/llvm-project/llvmorg-15-init-16436-g18a6ab5b8d1f, vendor/unbound/1.16.1, vendor/sqlite3/sqlite-3390000
# 86cdadbe 07-Jul-2022 Gleb Smirnoff <glebius@FreeBSD.org>

tree(3): allow the compare function to return any signed type

This allows to write very short comparison function when we are
comparing just pointer values:

return ((intptr_t)((uintptr_t)a->ptr/2

tree(3): allow the compare function to return any signed type

This allows to write very short comparison function when we are
comparing just pointer values:

return ((intptr_t)((uintptr_t)a->ptr/2 - (uintptr_t)b->ptr/2));

Reviewed by: dougm, alc
Differential revision: https://reviews.freebsd.org/D35722

show more ...


Revision tags: vendor/openssl/1.1.1q
# 2120d7f5 04-Jul-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: fine-tune rebalancing code

Change parts of RB_INSERT_COLOR and RB_REMOVE_COLOR to reduce the
number of operations, by, in some cases, flipping two color bits at a
time instead of flipping e

rb_tree: fine-tune rebalancing code

Change parts of RB_INSERT_COLOR and RB_REMOVE_COLOR to reduce the
number of operations, by, in some cases, flipping two color bits at a
time instead of flipping each individually, in separate operations,
and by using a switch statement to replace a sequence of if-elses.
Rewrite RB_SET_PARENT to generate fewer instructions. These changes
reduce the code size by over 100 bytes on some architectures.

Also, allow RB users to define a preprocessor symbol to generate
RB_REMOVE_COLOR code that matches the implementation described in the
original weak-AVL paper in one particular case, instead of the still
correct, but slightly more efficient implementation of that case
currently implemented.

Reviewed by: alc
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D35524

show more ...


Revision tags: vendor/file/5.42, vendor/llvm-project/llvmorg-15-init-15358-g53dc0f107877
# 91b30f7a 30-Jun-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: silence coverity

Add comments to RB_INSERT_COLOR to silence coverity warnings about the
use of an uninitialized variable. Since other static analyzers will
complain too, add a comment to e

rb_tree: silence coverity

Add comments to RB_INSERT_COLOR to silence coverity warnings about the
use of an uninitialized variable. Since other static analyzers will
complain too, add a comment to explain why the complaints are unwarranted.

Reviewed by: markj
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D35671

show more ...


# 61c74fb6 25-Jun-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: optimize tree rotation

The RB_ROTATE macros begin with fetching a field via a pointer. In
most cases, that value is one that has already been pulled into a
register, and the compiler cannot

rb_tree: optimize tree rotation

The RB_ROTATE macros begin with fetching a field via a pointer. In
most cases, that value is one that has already been pulled into a
register, and the compiler cannot infer that. So, to eliminate those
needless fetches, have the caller of the RB_ROTATE macros present the
data in the third macro parameter, rather than having the macro fetch
it.

Differential Revision: https://reviews.freebsd.org/D35520

show more ...


Revision tags: vendor/openssl/1.1.1p, vendor/bc/5.3.3, vendor/bc/5.3.2, vendor/llvm-project/llvmorg-14.0.5-0-gc12386ae247c, vendor/bc/5.3.1, vendor/bc/5.3.0
# 36447829 10-Jun-2022 Doug Moore <dougm@FreeBSD.org>

rb_tree: drop needless tests from rb_next, rb_prev

In RB_NEXT, when there is no RB_RIGHT node, the search must proceed
through the parent node.

There is code written to handle the case when the par

rb_tree: drop needless tests from rb_next, rb_prev

In RB_NEXT, when there is no RB_RIGHT node, the search must proceed
through the parent node.

There is code written to handle the case when the parent is non-NULL
and the current element is the left child of that parent. If you
assume that the current element is either the left child of its
parent, or the right child of its parent, but not both, then this test
is not necessary. Instead of assigning RB_PARENT(elm, field) to elm
when elm == RB_LEFT, removing the test has the code assign
RB_PARENT(elm, field) to elm when elm != RB_RIGHT. There's no need to
examine the RB_LEFT field at all.

This change removes that needless RB_LEFT test, and makes a similar
change to the RB_PREV implementation.

Reviewed by: alc
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35450

show more ...


12345678910>>...14