diff options
| author | serge-sans-paille <sguelton@redhat.com> | 2021-04-13 16:14:32 +0200 |
|---|---|---|
| committer | serge-sans-paille <sguelton@redhat.com> | 2021-04-16 22:48:33 +0200 |
| commit | 550ed575cbbd2c81cb855d4debb4a215ae75ef1e (patch) | |
| tree | 18cda10e4365f08db6649db4b5099c4c1115ab9b /clang/lib/CodeGen/CodeGenFunction.cpp | |
| parent | ca6751043d8899b12baeb48621e61fb352cfee09 (diff) | |
| download | llvm-550ed575cbbd2c81cb855d4debb4a215ae75ef1e.zip llvm-550ed575cbbd2c81cb855d4debb4a215ae75ef1e.tar.gz llvm-550ed575cbbd2c81cb855d4debb4a215ae75ef1e.tar.bz2 | |
Simplify BitVector code
Instead of managing memory by hand, delegate it to std::vector. This makes the
code much simpler, and also avoids repeatedly computing the storage size.
According to valgrind --tool=callgrind, this also slightly decreases the
instruction count, but by a small margin.
This is a recommit of 82f0e3d3ea6bf927e3397b2fb423abbc5821a30f with one usage
fixed in llvm/lib/CodeGen/RegisterScavenging.cpp.
Not the slight API change: BitVector::clear() now has the same behavior as any
other container: it does not free memory, but indeed sets the size of the
BitVector to 0. It is thus incorrect to access its content right afterwards, a
scenario which wasn't enforced in previous implementation.
Differential Revision: https://reviews.llvm.org/D100387
Diffstat (limited to 'clang/lib/CodeGen/CodeGenFunction.cpp')
0 files changed, 0 insertions, 0 deletions