| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The above change assumed that malloc (and friends) would always
allocate memory to getNewAlign(), even for allocations which have a
smaller size. This is not actually required by spec (a 1-byte
allocation may validly have 1-byte alignment).
Some real-world malloc implementations do not provide this guarantee,
and thus this optimization is breaking programs.
Fixes #53540
This reverts commit c2297544c04764237cedc523083c7be2fb3833d4.
Differential Revision: https://reviews.llvm.org/D118804
(cherry picked from commit 9545976ff160e19805a84a06a7e59d446f9994d9)
|
|
The original warning added in D115501 when pacbti is used with an
incompatible architecture was not exactly correct because it was
not really ignored and can affect codegen.
Therefore reword to say that the pacbti option is incompatible with
the given architecture.
Reviewed By: chill
Differential Revision: https://reviews.llvm.org/D119166
(cherry picked from commit 424e850f1ebc3e7011cb4af44cb2d62c02a58fbe)
|
|
While investigating the failures of `symbolize_pc.cpp` and
`symbolize_pc_inline.cpp` on SPARC (both Solaris and Linux), I noticed that
`__builtin_extract_return_addr` is a no-op in `clang` on all targets, while
`gcc` has non-default implementations for arm, mips, s390, and sparc.
This patch provides the SPARC implementation. For background see
`SparcISelLowering.cpp` (`SparcTargetLowering::LowerReturn_32`), the SPARC
psABI p.3-12, `%i7` and p.3-16/17, and SCD 2.4.1, p.3P-10, `%i7` and
p.3P-15.
Tested (after enabling the `sanitizer_common` tests on SPARC) on
`sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D91607
(cherry picked from commit efdd0a29b7eb6f3b6ca3fe9182a6c1085806c73a)
|
|
archive
(cherry picked from commit 99580e29d821beeaf75345deb3e4cc2c6808bfc0)
|
|
This is an intentionally limited/different form of D90113.
That patch bravely tries to generalize folds where we pull
a binop into the arms of a select:
N0 + (Cond ? 0 : FVal) --> Cond ? N0 : (N0 + FVal)
...but it is not universally profitable.
This is the inverse of IR canonicalization as discussed in
D113442.
We know that this transform is not entirely profitable even
within x86, so we only handle x86 vector fadd/fsub as a 1st
step. The intent is to prevent AVX512 regressions as mentioned
in D113442.
The plan is to port this to DAGCombiner (so it will eventually
look more like D90113) and add more types/cases in pieces with
many more tests to verify that we are seeing improvements.
Differential Revision: https://reviews.llvm.org/D118644
(cherry picked from commit 6592bcecd4ffc03f72d23f81bcb8d51f8ebeb07d)
|
|
This patch drops throws specifier in posix_memalign declaration because
that's different between glibc and other libc, and Clang has a hack.
Differential Revision: https://reviews.llvm.org/D117972
(cherry picked from commit f2f4080c10f4319adf75c660425911cd4e0e1843)
|
|
The documentation for the official (downstream) Qualcomm Hexagon Clang
states that -mhvx sets the HVX version to be the same as the CPU version.
The current implementation upstream would use the most recent versioned
-mhvx= flag first (if present), then the CPU version. Change the upstream
behavior to match the documented behavior of the downstream compiler.
(cherry picked from commit 2ecda9ec9cc89b87ce2e56452229c9444beabf21)
|
|
The helper `Attributor::checkForAllReturnedValuesAndReturnInsts`
simplifies the returned value optimistically. In `AAUndefinedBehavior`
we cannot use such optimistic values when deducing UB. As a result, we
assumed UB for the return value of a function because we initially
(=optimistically) thought the function return is `undef`. While we later
adjusted this properly, the `AAUndefinedBehavior` was under the
impression the return value is "known" (=fix) and could never change.
To correct this we use `Attributor::checkForAllInstructions` and then
manually to perform simplification of the return value, only allowing
known values to be used. This actually matches the other UB deductions.
Fixes #53647
(cherry picked from commit dd101c808b85aad8edb48ab6d5f754cc6527fcff)
|
|
!SANITIZER_GO after D119007
The SANITIZER_GO code path reports an undefined symbol error for dlsym.
```
FAILED: projects/compiler-rt/lib/tsan/rtl/CMakeFiles/GotsanRuntimeCheck /tmp/RelA/projects/compiler-rt/lib/tsan/rtl/CMakeFiles/GotsanRuntimeCheck
```
(cherry picked from commit f0cdacd99bd41dbd778099dfe303ba92660826b3)
|
|
This symbol has been exported (as an internal GLIBC_PRIVATE symbol) from libc.so.6 starting with glibc 2.34. glibc uses it internally for its libthread_db implementation to enable thread debugging on GDB, so it is unlikely to go away for now.
Fixes #52989.
Reviewed By: #sanitizers, MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D119007
(cherry picked from commit ef14b78d9a144ba81ba02083fe21eb286a88732b)
|
|
This patch replaces the ValueRAII pointer with a default 'nullptr'
value. Previously this was initialized as a reference to an existing
variable. The use of this variable caused overhead as the compiler could
not look through the uses and determine that it was unused if 'Active'
was not set. Because of this accesses to the variable would be left in
the runtime once compiled.
Fixes #53641
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D119187
(cherry picked from commit d28051c4ab44141d7c52902de500dfe1293d3de2)
|
|
The linker wrapper tool uses the 'nvlink' and 'ptxas' binaries to link
and assemble device files. Previously we searched for this using the
binaries in the user's path. This didn't work in cases where the user
passed in a specific Cuda path to Clang. This patch changes the linker
wrapper to accept an argument for the Cuda path we can get from Clang.
This should fix #53573.
Reviewed By: tianshilei1992
Differential Revision: https://reviews.llvm.org/D118944
(cherry picked from commit 8cc4ca95b02bc5b5b668b3d537b45a6585575cba)
|
|
- Add or remove empty lines surrounding union blocks.
- Fixes https://github.com/llvm/llvm-project/issues/53229, in which
keywords like class and struct in a line ending with left brace or
whose next line is left brace only, will be falsely recognized as
definition line, causing extra empty lines inserted surrounding blocks
with no need to be formatted.
Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D119067
(cherry picked from commit a70549ae43dfa551f3eacdfa7a7f2c0df073be8e)
|
|
After aed965d we no longer demangle full symbol names while indexing the
symbol table which means we have to use the mangled name instead of the
demangled name to find the symbol for __asan::AsanDie().
This fixes the following two tests:
lldb-api :: functionalities/asan/TestMemoryHistory.py
lldb-api :: functionalities/asan/TestReportData.py
(cherry picked from commit ef3fade14b32c20e0a35b8fca30e7d2f20e0c983)
|
|
This addresses Pavel's comment from D118814.
(cherry picked from commit edbb0f6df76b04100357c7c9438f3b5b978e0200)
|
|
The symbol table needs to demangle all symbol names when building its
index. However, this doesn't require the full mangled name: we only need
the base name and the function declaration context. Currently, we always
construct the demangled string during indexing and cache it in the
string pool as a way to speed up future lookups.
Constructing the demangled string is by far the most expensive step of
the demangling process, because the output string can be exponentially
larger than the input and unless you're dumping the symbol table, many
of those demangled names will not be needed again.
This patch avoids constructing the full demangled string when we can
partially demangle. This speeds up indexing and reduces memory usage.
I gathered some numbers by attaching to Slack:
Before
------
Memory usage: 280MB
Benchmark 1: ./bin/lldb -n Slack -o quit
Time (mean ± σ): 4.829 s ± 0.518 s [User: 4.012 s, System: 0.208 s]
Range (min … max): 4.624 s … 6.294 s 10 runs
After
-----
Memory usage: 189MB
Benchmark 1: ./bin/lldb -n Slack -o quit
Time (mean ± σ): 4.182 s ± 0.025 s [User: 3.536 s, System: 0.192 s]
Range (min … max): 4.152 s … 4.233 s 10 runs
Differential revision: https://reviews.llvm.org/D118814
(cherry picked from commit aed965d55d460ebcc2b442b9d799b4c1ab929157)
|
|
Have the different ::Parse.* methods return the demangled string
directly instead of having to go through ::GetBufferRef.
Differential revision: https://reviews.llvm.org/D118953
(cherry picked from commit fa52788b7a6da1eab9fec0f2db5f74a8db555196)
|
|
op uses"
This reverts commit b4b97ec813a02585000f30ac7d532dda74e8bfda.
As discussed in post-commit feedback at:
https://reviews.llvm.org/D118376
...there's a stage 2 failure on a Mac running a clang-refactor tool test.
(cherry picked from commit 7b03725097872fbd3369a7213c1d98b372aa2d78)
|
|
This patch is a sticking-paster until D118774 solves the situation with
unique_ptrs. I'm certainly wishing I'd focused on that first X_X.
(cherry picked from commit 4654fa89eacca375ff860203697982b873bbd7c8)
|
|
Reviewed By: amilendra
Differential Revision: https://reviews.llvm.org/D119008
|
|
When LLVM_ENABLE_ZLIB is ON gdb-remote should link against ZLIB::ZLIB.
This fixes
```
/mnt/b/yoe/master/build/tmp/hosttools/ld: lib/liblldbPluginProcessGDBRemote.a(GDBRemoteCommunication.cpp.o): in function `lldb_private::process_gdb_remote::GDBRemoteCommunication::DecompressPacket() [clone .localalias]':
GDBRemoteCommunication.cpp:(.text._ZN12lldb_private18process_gdb_remote22GDBRemoteCommunication16DecompressPacketEv+0x59a): undefined reference to `inflateInit2_'
/mnt/b/yoe/master/build/tmp/hosttools/ld: GDBRemoteCommunication.cpp:(.text._ZN12lldb_private18process_gdb_remote22GDBRemoteCommunication16DecompressPacketEv+0x5af): undefined reference to `inflate'
```
Reviewed By: JDevlieghere, MaskRay
Differential Revision: https://reviews.llvm.org/D119186
(cherry picked from commit 385f5c4d33799df25a85ceb54b6232499cb8a78d)
|
|
We were assuming that the symbol versions for libclang.so would be different
for each major release, but this is not longer true. The libclang.so symbol
versions only change when the ABI changes.
|
|
Generate movprfx for floating point convert zeroing pseudo operations
Differential Revision: https://reviews.llvm.org/D118617
(cherry picked from commit 6b73a4cc7db96af1dd02db68c07fe4a807104c53)
|
|
As discussed in D118534, all of the recent AMD CPUs have
relatively fast (<14 cycle latency) "sqrtss" and "sqrtps"
instructions:
https://uops.info/table.html?search=sqrtps&cb_lat=on&cb_tp=on&cb_SNB=on&cb_SKL=on&cb_ZENp=on&cb_ZEN2=on&cb_ZEN3=on&cb_measurements=on&cb_avx=on&cb_sse=on
So we should set this tuning flag to alter codegen of plain
"sqrt(X)" expansion (as opposed to reciprocal-sqrt - there
is other test coverage for that pattern). The expansion is
both slower and less accurate than the hardware instruction.
Differential Revision: https://reviews.llvm.org/D119001
(cherry picked from commit fff3e1dbaa9ee2d91dc15b39defa88346f03a4c2)
|
|
(cherry picked from commit 1eb4f88bfef1ab93b8286fdfd05a8b814507e329)
|
|
When the main loop is e.g. VF=vscale x 1 and the epilogue VF cannot
be any smaller, the vectorizer should try to estimate how many lanes are
executed at runtime and allow a suitable fixed-width VF to be chosen. It
can use VScaleForTuning to figure out what a suitable fixed-width VF could
be. For the case where the main loop VF is VF=vscale x 1, and VScaleForTuning=8,
it could still choose an epilogue VF upto VF=4.
This was a bit tricky to test, so this patch also introduces a wrapper
function to get 'VScaleForTuning' by also considering vscale_range.
If min and max are equal, then that will be the vscale we compile for.
It makes little sense to tune for a different width if the code
will not be portable for other widths.
Reviewed By: david-arm
Differential Revision: https://reviews.llvm.org/D118709
(cherry picked from commit eaee477edafed691dae206cea7c0a42893eb2821)
|
|
- If not using `llvm-config`, `LLVM_MAIN_SRC_DIR` now has a sane default
- `LLVM_CONFIG_PATH` will continue to work for LLD for back compat.
- More quoting of paths in an abundance of caution.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D118792
(cherry picked from commit e0eeae9a447004cc346d9bf36c0d02f45e276a7c)
|
|
Similar to 60cc1d3218fc for NetBSD, add aliases and interceptors for the
following pthread related functions:
- pthread_cond_init(3)
- pthread_cond_destroy(3)
- pthread_cond_signal(3)
- pthread_cond_broadcast(3)
- pthread_cond_wait(3)
- pthread_mutex_init(3)
- pthread_mutex_destroy(3)
- pthread_mutex_lock(3)
- pthread_mutex_trylock(3)
- pthread_mutex_unlock(3)
- pthread_rwlock_init(3)
- pthread_rwlock_destroy(3)
- pthread_rwlock_rdlock(3)
- pthread_rwlock_tryrdlock(3)
- pthread_rwlock_wrlock(3)
- pthread_rwlock_trywrlock(3)
- pthread_rwlock_unlock(3)
- pthread_once(3)
- pthread_sigmask(3)
In FreeBSD's libc, a number of internal aliases of the pthread functions
are invoked, typically with an additional prefixed underscore, e.g.
_pthread_cond_init() and so on.
ThreadSanitizer needs to intercept these aliases too, otherwise some
false positive reports about data races might be produced.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D119034
(cherry picked from commit 28fb22c90fe73877c529ddae74b9fe30a3a09234)
|
|
Clang-format LLVM style has a custom include category for gtest/ and
gmock/ headers between regular includes and angled includes. Do the same here.
Fixes https://github.com/llvm/llvm-project/issues/53525.
Differential Revision: https://reviews.llvm.org/D118913
(cherry picked from commit 0447ec2fb050eb37ed1f5991a1562dea6e228f9e)
|
|
After discussion in D116821 this was turned off in 74db5c8c95e,
14aaaa12366f7 applied to limit the maximum memory consumption in rare
conditions, plus some performance patches.
(cherry picked from commit 6e03a68b776dc06826dacbdab26d24a90bb2173b)
|
|
This is a follow-up to D117877: variable assignments of DBG_VALUE $noreg,
or DBG_INSTR_REFs where no value can be found, are represented by a
DbgValue object with Kind "Undef", explicitly meaning "there is no value".
In D117877 I added a special-case to some assignment accounting faster,
without considering this scenario. It causes variables to be given the
value ValueIDNum::EmptyValue, which then ends up being a DenseMap key. The
DenseMap asserts, because EmptyValue is the tombstone key.
Fix this by handling the assign-undef scenario in the special case, to
match what happens in the general case: the variable has no value if it's
only ever assigned $noreg / undef.
Differential Revision: https://reviews.llvm.org/D118715
(cherry picked from commit 43de305704a50983bf134d8fb916f752a02eb076)
|
|
Gaps in the basic block number range (from blocks being deleted or folded)
get block-value-tables allocated but never ejected, leading to a memory
leak, currently tripping up the asan buildbots. Fix this up by manually
freeing that memory.
As suggested elsewhere, if these things were owned by a unique_ptr then
cleanup would happen automagically. D118774 should eliminate the need for
this dance.
(cherry picked from commit 206cafb680cea0741f8c7b276351db516ff27f81)
|
|
This patch aims to reduce max-rss from instruction referencing, by avoiding
keeping variable value information in memory for too long. Instead of
computing all the variable values then emitting them to DBG_VALUE
instructions, this patch tries to stream the information out through a
depth first search:
* Make use of the fact LexicalScopes gives a depth-number to each lexical
scope,
* Produce a map that identifies the last lexical scope to make use of a
block,
* Enumerate each scope in LexicalScopes' DFS order, solving the variable
value problem,
* After each scope is processed, look for any blocks that won't be used by
any other scope, and emit all the variable information to DBG_VALUE
instructions.
Differential Revision: https://reviews.llvm.org/D118460
(cherry picked from commit 9fd9d56dc6bdeeddf8cf2af834c6c39d00cd7244)
|
|
This patch releases some memory from InstrRefBasedLDV earlier that it would
otherwise. The underlying problem is:
* We store a big table of "live in values for each block",
* We translate that into DBG_VALUE instructions in each block,
And both exist in memory at the same time, which needlessly doubles that
information. The most of what this patch does is: as we progressively
translate live-in information into DBG_VALUEs, we free the variable-value /
machine-value tracking information as we go, which significantly reduces
peak memory.
While I'm here, also add a clear method to wipe variable assignments that
have been accumulated into VLocTracker objects, and turn a DenseMap into
a SmallDenseMap to avoid an initial allocation.
Differential Revision: https://reviews.llvm.org/D118453
(cherry picked from commit a80181a81ea44215e49e5da1457614ec0bd44111)
|
|
Install a cache of DBG_INSTR_REF -> ValueIDNum resolutions, for scenarios
where the value has to be reconstructed from several DBG_PHIs. Whenever
this happens, it's because branch folding + tail duplication has messed
with the SSA form of the program, and we have to solve a mini SSA problem
to find the variable value. This is always called twice, so it makes sense
to cache the value.
This gives a ~0.5% geomean compile-time-performance improvement on CTMark.
Differential Revision: https://reviews.llvm.org/D118455
(cherry picked from commit d556eb7e27c25ae20befb0811bc8a3423241431d)
|
|
Was reverted in 1c1b670a73a9 as it broke all non-x86 bots. Original commit
message:
[DebugInfo][InstrRef] Add a max-stack-slots-to-track cut-out
In certain circumstances with things like autogenerated code and asan, you
can end up with thousands of Values live at the same time, causing a large
working set and a lot of information spilled to the stack. Unfortunately
InstrRefBasedLDV doesn't cope well with this and consumes a lot of memory
when there are many many stack slots. See the reproducer in D116821.
It seems very unlikely that a developer would be able to reason about
hundreds of live named local variables at the same time, so a huge working
set and many stack slots is an indicator that we're likely analysing
autogenerated or instrumented code. In those cases: gracefully degrade by
setting an upper bound on the amount of stack slots to track. This limits
peak memory consumption, at the cost of dropping some variable locations,
but in a rare scenario where it's unlikely someone is actually going to
use them.
In terms of the patch, this adds a cl::opt for max number of stack slots to
track, and has the stack-slot-numbering code optionally return None. That
then filters through a number of code paths, which can then chose to not
track a spill / restore if it touches an untracked spill slot. The added
test checks that we drop variable locations that are on the stack, if we
set the limit to zero.
Differential Revision: https://reviews.llvm.org/D118601
(cherry picked from commit 14aaaa12366f7d1328b5ec81c71c63de9d878e75)
|
|
https://github.com/llvm/llvm-project/issues/53567
The following source
```
namespace A {
template <int N> struct Foo<char[N]> {
void foo() { std::cout << "Bar"; }
}; // namespace A
```
is incorrectly formatted as:
```
namespace A {
template <int N> struct Foo<char[N]>{void foo(){std::cout << "Bar";
}
}
; // namespace A
```
This looks to be caused by https://github.com/llvm/llvm-project/commit/5c2e7c9ca043d92bed75b08e653fb47c384edd13
Reviewed By: curdeius
Differential Revision: https://reviews.llvm.org/D118911
(cherry picked from commit 23fc20e06c088acff81a06ad546a848bee083051)
|
|
Adds libunwind support for SPARCv9 (aka sparc64). This is a rebase of @kettenis' patch D32450, which I created (with his permission) because the original review has become inactive.
The changes are of a cosmetic nature to make it fit better with the new code style, and to reuse the existing SPARCv8 code, whenever possible.
Please let me know if I posted this on the wrong place. Also, the summary of the original review is reproduced below:
> This adds unwinder support for 64-bit SPARC (aka SPARCv9). The implementation was done on OpenBSD/sparc64, so it takes StackGhost into account:
>
> https://www.usenix.org/legacy/publications/library/proceedings/sec01/full_papers/frantzen/frantzen_html/index.html
>
> Since StackGhost xor's return addresses with a random cookie before storing them on the stack, the unwinder has to do some extra work to recover those. This is done by introducing a new kRegisterInCFADecrypt "location" type that is used to implement the DW_CFA_GNU_window_save opcode. That implementation is SPARC-specific, but should work for 32-bit SPARC as well. DW_CFA_GNU_window_save is only ever generated on SPARC as far as I know.
Co-authored-by: Mark Kettenis
Reviewed By: #libunwind, thesamesam, MaskRay, Arfrever
Differential Revision: https://reviews.llvm.org/D116857
(cherry picked from commit 2b9554b8850192bdd86c02eb671de1d866df8d87)
|
|
Similar to D116843 for Gnu.cpp
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D119071
(cherry picked from commit 1831cbd9d4174a93d4017e510ecf0f840af5f7d6)
|
|
Add SPARC to the list of platforms for which we provide a full
unwind implementation which leads to _Unwind_Backtrace being defined within
libunwind.so.
Likewise for PPC (see D118320 for background).
Reviewed By: #libunwind, MaskRay, Arfrever
Differential Revision: https://reviews.llvm.org/D119068
(cherry picked from commit 022011078054c133777e1c3f8ea927bdef97f1fc)
|
|
|
|
lld/ELF/OutputSections.cpp includes llvm/Config/config.h for
LLVM_ENABLE_ZLIB definition, but llvm/Config/config.h doesn't exist in
standalone build.
To fix this, this patch moves LLVM_ENABLE_ZLIB from config.h to
llvm-config.h and updates OutputSections.cpp to include llvm-config.h
instead of config.h
Reviewed By: MaskRay, mgorny
Differential Revision: https://reviews.llvm.org/D119058
(cherry picked from commit e8bff9ae54a55b4dbfeb6ba55f723abbd81bf494)
|
|
This issue is an oversight in D108621.
Literals in HIP are emitted as global constant variables with default
address space which maps to Generic address space for HIPSPV. In
SPIR-V such variables translate to OpVariable instructions with
Generic storage class which are not legal. Fix by mapping literals
to CrossWorkGroup address space.
The literals are not mapped to UniformConstant because the “flat”
pointers in HIP may reference them and “flat” pointers are modeled
as Generic pointers in SPIR-V. In SPIR-V/OpenCL UniformConstant
pointers may not be casted to Generic.
Patch by: Henry Linjamäki
Reviewed by: Yaxun Liu
Differential Revision: https://reviews.llvm.org/D118876
|
|
Microsoft CXX ABI was added.
This mentions the change in the release notes.
Differential revision: https://reviews.llvm.org/D117500
|
|
The diagnostic is concise. It is ok because the case is rare.
(cherry picked from commit bad1b7fbb0fec532f097ac59805562020f895962)
|
|
musl does not set errno in math functions: https://wiki.musl-libc.org/mathematical-library.html, https://git.musl-libc.org/cgit/musl/tree/include/math.h?id=cfdfd5ea3ce14c6abf7fb22a531f3d99518b5a1b#n26.
Reviewed By: srhines, MaskRay
Differential Revision: https://reviews.llvm.org/D116753
(cherry picked from commit 38449c98f3d33dffdaf7e1feeb9dfdcf63b5126b)
|
|
after D112759
(cherry picked from commit 42f9ca55dd487580cfd32d4b803315d789442442)
|
|
D112753
(cherry picked from commit 3dd2d4c0a239ce78421d51491456cb1a075ad2f3)
|
|
Similar to f457863ae345d2635026501f5383e0e625869639
(cherry picked from commit 53fc5d9b9a0110f097c6e9f7aa3bff3621eaf268)
|
|
(cherry picked from commit c161b30f5c23ef9fe246d6bdf875c5a08cf2df9f)
|
