| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
PiperOrigin-RevId: 557187112
Change-Id: I7c3e4be0ab5a7451173da7a0ded53a3d227bb093
|
|
|
|
|
| |
PiperOrigin-RevId: 556065631
Change-Id: I7e69b1495946c42fab185a1bc23e9564bfbd5e41
|
|
|
|
|
| |
PiperOrigin-RevId: 555894810
Change-Id: I349c94e7c6e7ba1dbd817aa8e4340c1dada84654
|
|
|
|
|
|
|
| |
sampling the current allocation.
PiperOrigin-RevId: 553847957
Change-Id: Idd131d0362bf36bd22d9bd20df54bd9ae50f0e28
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we require only a single bit to be set in each abstract bit for iterable bitmasks. However, in most cases, where we have a single match, or no matches in a group, iteration is not needed. We move the masking to the iteration function instead of having it as a requirement for iterable Bitmask construction.
This is 4-8% faster for Find and Insert operations.
This can hurt performance if we need to iterate many times (there are many matches in the same Group), however this is unlikely, even if we assume the table is completely full.
If there are 0 or 1 matches in a group, or the first match is the correct item we are looking for, we save 1 instruction/cycle (most cases)
If there are 2 matches in a group, and the first is a false positive, this is neutral (< 3%)
If there are more than 2 matches in a group and the first two are false positives, this can be slower by 1 cycle/instruction per additional iteration (< 0.1%)
No change to x86.
PiperOrigin-RevId: 553831814
Change-Id: I08620899847eaf0086da989d829a1029ea24173a
|
|
|
|
|
|
|
| |
the field and store it together with size_.
PiperOrigin-RevId: 553499768
Change-Id: Ia6eec6d580475a2b76a2415bfb35bcc08131ae34
|
|
|
|
|
|
|
| |
invalidated by rehashing
PiperOrigin-RevId: 552901078
Change-Id: I137d01fe87b1bbf591b400305f6f7919982fc1c9
|
|
|
|
|
|
|
|
|
|
| |
as well. Some empty cases can trigger this.
See also:
https://clang.llvm.org/docs/ControlFlowIntegrity.html#bad-cast-checking.
PiperOrigin-RevId: 552846765
Change-Id: I6adb3c0c73efec841ffe8fdac4342f641c68ddbe
|
|
|
|
|
| |
PiperOrigin-RevId: 552520562
Change-Id: I5d311871afbc2906894c3b754a503a6abace8ceb
|
|
|
|
|
|
|
|
| |
the results of a bunch of accessors of CommonFields.
Motivation: this makes it easier to refactor CommonFields to be smaller.
PiperOrigin-RevId: 551616928
Change-Id: I3710443fb156537d716944584bea02f945559e99
|
|
|
|
|
|
|
|
|
|
| |
heap allocation path. The cast occurs before the memory is initialized.
See also:
https://clang.llvm.org/docs/ControlFlowIntegrity.html#bad-cast-checking.
PiperOrigin-RevId: 551542366
Change-Id: Id5834892c36a5cb8ec095bcfee3e9e31f20c48ae
|
|
|
|
|
|
|
| |
calling erase(begin(), end()) resets reserved growth.
PiperOrigin-RevId: 551248712
Change-Id: I34755c63e3ee40da4ba7047e0d24eec567d28173
|
|
|
|
|
|
|
|
|
|
|
|
| |
GetInlinedDataUninitialized() is removed. Just use GetInlinedData() in
all cases instead. GetInlinedData() is sometimes used to return
uninitialized memory. In these cases it is immediately constructed.
This is a followup to 511ad64. See also:
https://clang.llvm.org/docs/ControlFlowIntegrity.html#bad-cast-checking.
PiperOrigin-RevId: 551205766
Change-Id: I4ddb45e29a723ccf6fc7dc203e762f4ad559fc83
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a vtable
The code is getting the pointer, then constructing it on the next
line. Using reinterpret_cast on this pointer is legal according to
https://clang.llvm.org/docs/ControlFlowIntegrity.html#bad-cast-checking,
but it flags it anyway. The docs say it might be necessary for
`allocate()`-type APIs, and recommends adding them to an ignorelist.
Also note that std::addressof is removed. It is unnecessary since
inlined_data is a char-array.
PiperOrigin-RevId: 550972834
Change-Id: Ib224cec330bb6bcb770296de6c91881f404ef531
|
|
|
|
|
|
|
|
| |
motivation is to avoid potentially expanding the table unnecessarily later.
Note: I prefer doing this as a special case in erase(iterator, iterator) rather than special casing erase(iterator) for size==1 because IIUC that changes the time complexity of erase(iterator) from O(1) to O(N) and in pathological cases, it could change loops from O(N) to O(N^2).
PiperOrigin-RevId: 549661855
Change-Id: I8603324260f51a98809db32f840ff09f25cf2481
|
|
|
|
|
|
|
| |
corresponding function in raw_hash_set.
PiperOrigin-RevId: 549379884
Change-Id: I305745dbea2c15821b2092441c9b4546fc7aabbe
|
|
|
|
|
| |
PiperOrigin-RevId: 548794485
Change-Id: Ie82d5f8ad752518ef05b38144ca1e32b21c9def8
|
|
|
|
|
|
|
| |
fails.
PiperOrigin-RevId: 545683736
Change-Id: Ic0abec5037e160898e2f24de1b1489caff7d06fd
|
|
|
|
|
|
|
| |
easier to change how we store this information internally.
PiperOrigin-RevId: 544732832
Change-Id: I0c9a30f18edc71b3c7fffe94e2002ff6c52050f8
|
|
|
|
|
|
|
| |
to change how we store this information internally.
PiperOrigin-RevId: 544718317
Change-Id: I0ff3e4df7e810be9f7c5db4328995e172eb704a5
|
|
|
|
|
|
|
| |
how we store this information internally.
PiperOrigin-RevId: 544667586
Change-Id: I9b1943ca71ea1c1f8699832422cd7bc095ac8b2d
|
|
|
|
|
| |
PiperOrigin-RevId: 544401753
Change-Id: Ie5bb48bb46c8c1bf41ef902242cefefd739e7c37
|
|
|
|
|
| |
PiperOrigin-RevId: 540928490
Change-Id: Idf022b28ce101a948be4efd5336888a66f5eacf9
|
|
|
|
| |
https://google.github.io/styleguide/cppguide.html#Function_Comments
|
|\
| |
| |
| |
| | |
PiperOrigin-RevId: 536785792
Change-Id: I2963dea81a75b01b7275d784f6a2908816d0c7bf
|
| | |
|
| |
| |
| |
| |
| | |
PiperOrigin-RevId: 535534819
Change-Id: Iccf8da3e0b084131e4c0dba205f3e190d3a66f4e
|
|/
|
|
|
|
|
|
|
|
|
| |
The non-RAW_ versions provide better output but weren't available when most of these tests were written.
There are just a couple spots where RAW_ is actually needed, e.g. signal handlers and malloc hooks.
Also fix a couple warnings in layout_test.cc newly surfaced because the optimizer understands CHECK_XX differently than INTERNAL_CHECK.
PiperOrigin-RevId: 534584435
Change-Id: I8d36fa809ffdaae5a3813064bd602cb8611c1613
|
|
|
|
|
|
|
|
|
| |
equal to field_type.
Also do some minor refactoring in btree.h.
PiperOrigin-RevId: 529460378
Change-Id: I278833ada93bbb7652e149fceed08ce3485e4312
|
|
|
|
|
|
|
| |
from internal ones.
PiperOrigin-RevId: 529423722
Change-Id: Ib1cc427299100956c0f2ae6cb5214467ef5a3790
|
|
|
|
|
| |
PiperOrigin-RevId: 529119690
Change-Id: If585274c409e2a344c8d60759da6f8f990023d29
|
|\
| |
| |
| |
| | |
PiperOrigin-RevId: 529086715
Change-Id: Id5462322d5707a1b4475438520fcb70ee7b15450
|
|/ |
|
|
|
|
|
|
|
| |
When we insert a new element, when ASan is enabled, we replace the node that the new element is on in order to try to detect cases of code depending on pointer/reference-stability.
PiperOrigin-RevId: 528826645
Change-Id: Ie5c15c13016a8aa831a0d1edc3ad33c1f5ca4d65
|
|\
| |
| |
| |
| | |
PiperOrigin-RevId: 527066823
Change-Id: Ifa1e9a43c7490b34f9f4dbfa12d3acbed6b49777
|
|/ |
|
|
|
|
|
|
|
| |
constructing nodes.
PiperOrigin-RevId: 525792213
Change-Id: I4386385e6e05d74a4ccc18cea505530e919f0e28
|
|
|
|
|
|
|
|
|
| |
i.e. comp(A,B) && comp(B,C) -> comp(A,C).
When inserting a new element, we verify that the key is ordered correctly with respect to all the other values on the node, which can be done in constant time.
PiperOrigin-RevId: 523729309
Change-Id: Idb5a5912a9aa5411d086cb9fa76791523046778a
|
|
|
|
|
|
|
| |
std::is_trivially_copyable
PiperOrigin-RevId: 523724345
Change-Id: Id68c79c3bbb253d892bdef4659ac8a926e023d12
|
|
|
|
|
|
|
| |
This has nothing to do with copy assignment or with destruction.
PiperOrigin-RevId: 523576913
Change-Id: Iddb6ab73bcfd8b01a29880cdf4db4bc2b5aead8a
|
|
|
|
|
|
|
| |
This has nothing to do with copy construction or copy assignment.
PiperOrigin-RevId: 523571907
Change-Id: I338b5a40616594406ca8c80b747540c8935798e9
|
|
|
|
|
|
|
| |
This has nothing to do with copy construction or copy assignment.
PiperOrigin-RevId: 523557887
Change-Id: I332d6ceaf738305157605f1271cb577a83d198c5
|
|
|
|
|
|
|
|
|
| |
Don't require a trivial move constructor and trivial destructor. This excludes
types that have declared themselves trivially relocatable by another means, like
std::unique_ptr. Instead use "is trivially relocatable" directly, which includes
all previous types as well as those that have opted in.
PiperOrigin-RevId: 523557136
Change-Id: Icea2dbb8f36f99623308155f2e5b1edd8e5bd36b
|
|
|
|
|
| |
PiperOrigin-RevId: 521556211
Change-Id: I1e1812eb11bfc5772abbf38ce348580c3afa5612
|
|
|
|
|
|
|
|
| |
We know that the elements are trivially destructible if this path is used, so
there is no need to call their destructors one by one.
PiperOrigin-RevId: 521088624
Change-Id: I3edff97a073770f99031eefa7a34968fad5d7880
|
|
|
|
|
|
|
|
|
| |
The fact that this is called from paths where the element type may not have a
trivial destructor is preventing an optimization (see the TODO). Stop calling
from those paths so that the optimization can be made in an upcoming CL.
PiperOrigin-RevId: 521087730
Change-Id: Id2b66d8f36bb0d294784d0793fdd8f07e315739f
|
|
|
|
|
|
|
|
| |
The copy constructor isn't doing or simulating copy assignment; nor is it
destroying anything. We don't need to require that those operations be trivial.
PiperOrigin-RevId: 521020499
Change-Id: I0f36a720384b333ea15e6c8275872fd4fd9a738f
|
|
|
|
|
|
|
|
|
| |
These have nothing to do with copy construction or copy assignment, and using
"is trivially copy constructible" can in theory even give the wrong result if
the copy constructor is trivial but the move constructor is not.
PiperOrigin-RevId: 520488816
Change-Id: I6da4d57f3ce23b03044e0bf9aa70a14b51651fa3
|
|
|
|
|
|
|
|
|
| |
There's no reason to require the type to be trivially
copy-constructible/assignable in order to avoid running destructors—those
traits have nothing to do with destruction.
PiperOrigin-RevId: 519822201
Change-Id: I2ed7bbb53f0c1a512017115ff29fb27a24c6b11a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This type trait had no precise definition, and indeed not even any documentation
at all. Giving the ill-defined concept a name was harmful, because it obscured
several places where the concept was used too conservatively, or even flat-out
incorrectly.
This CL has no behavior change: it simply expands IsMemcpyOk to the same
conditions it previously had. It leaves TODOs for each place where this was too
conservative or incorrect.
PiperOrigin-RevId: 519278325
Change-Id: I25bc89f299f6e40b5c3bce7370ed90f33a95612f
|