[lldb] [debugserver] address preprocessor warning, extra arg (#90808)
In DNBArchImplARM64.cpp I'm doing
```
#if __has_feature(ptrauth_calls) && defined(__LP64__)
```
And the preprocessor warns that this is not defined behavior. This
checks if ptrauth_calls is available and if this is being compiled
64-bit (i.e. arm64e), and defines a single DEBUGSERVER_IS_ARM64E when
those are both true.
I did have to duplicate one DNBLogThreaded() call which itself is a
macro, and using an ifdef in the middle of macro arguments also got me a
warning from the preprocessor.
While testing this for all the different targets, I found a DNBError
initialization that accepts a c-string but I'm passing in a printf-style
formatter c-string and an argument. Create the string before the call
and pass in the constructed string.
rdar://127129242
[clang][PGO] Apply artificial DebugLoc to llvm.instrprof.increment instructions (#90717)
Prior to this change the debug-location for the
`llvm.instrprof.increment` intrinsic was set to whatever the current
DIBuilder's current debug location was set to. This meant that for
switch-statements, a counter's location was set to the previous case's
debug-location, causing confusing stepping behaviour in debuggers. This
patch makes sure we attach a dummy debug-location for the increment
instructions.
rdar://123050737
[HLSL] Cleanup TargetInfo handling (#90694)
We had some odd places where we set target behaviors. We were setting
the long size in target-specific code, but it should be language-based.
We were not setting the Half float type semantics correctly, and instead
were overriding the query in the AST context.
This change it moves existing code to the right places in the Target so
that as we continue working on target and language feature they are
controlled in the right places.
It also fixes a bug where the size of `half` was computed incorrectly
when native half types are not supported.
Bump actions runner image used for libc++'s builders.
The builders are not producing warnings about the runner version being
out of date. This is an attempt to fix that.
[flang][cuda] Lower device/managed/unified allocation to cuda ops (#90623)
Lower locals allocation of cuda device, managed and unified variables to
fir.cuda_alloc. Add fir.cuda_free in the function context finalization.
@vzakhari For some reason the PR #90526 has been closed when I merged PR
#90525. Just reopening one.
[libcxx] Align `__recommend() + 1` by __endian_factor (#90292)
This is detected by asan after #83774
Allocation size will be divided by `__endian_factor` before storing. If
it's not aligned,
we will not be able to recover allocation size to pass into
`__alloc_traits::deallocate`.
we have code like this
```
auto __allocation = std::__allocate_at_least(__alloc(), __recommend(__sz) + 1);
__p = __allocation.ptr;
__set_long_cap(__allocation.count);
void __set_long_cap(size_type __s) _NOEXCEPT {
__r_.first().__l.__cap_ = __s / __endian_factor;
__r_.first().__l.__is_long_ = true;
}
[17 lines not shown]
[llvm][GraphWriter] Resize std::string, instead of reassigning to substr (NFC)
* Don't call substr which creates a new string instance
* Only call string method if string length is larger than 140
Closes #90324
[clang][CodeGen] Fix in codegen for __builtin_popcountg/ctzg/clzg (#90845)
Make sure that the result from the popcnt/ctlz/cttz intrinsics is
unsigned casted to int, rather than casted as a signed value, when
expanding the __builtin_popcountg/__builtin_ctzg/__builtin_clzg
builtins.
An example would be
unsigned _BitInt(1) x = ...;
int y = __builtin_popcountg(x);
which previously was incorrectly expanded to
%1 = call i1 @llvm.ctpop.i1(i1 %0)
%cast = sext i1 %1 to i32
Since the input type is generic for those "g" versions of the builtins
the intrinsic call may return a value for which the sign bit is set
(that could typically for BitInt of size 1 and 2). So we need to emit a
zext rather than a sext to avoid negative results.
[libc++] Granularize <ostream> (#85537)
This also includes `<__ostream/basic_ostream.h>` in `<sstream>` now,
reducing the include time of `<complex>` from 819ms to 603ms.
[BOLT] Refactor BOLT reserved space discovery (#90893)
Move code that checks for __bolt_reserved_{start,end} into a new
discoverBOLTReserved() function and call it from discoverFileObjects()
so that the reserved space info is accessible to passes. NFC for the
current set of binaries.
[BOLT] Add support for Linux kernel .smp_locks section (#90798)
Parse .smp_locks section entries and create fixups that are going to be
used to update the section before the binary emission.
[libc++][TZDB] Implements time_zone::to_sys.
This implements the overload with the choose argument and adds this enum.
Implements parts of:
- P0355 Extending chrono to Calendars and Time Zones
[AMDGPU] Use some merging/unmerging helpers in SILoadStoreOptimizer (#90866)
Factor out copyToDestRegs and copyFromSrcRegs for merging store sources
and unmerging load results. NFC.
SystemZ: Stop casting fp typed atomic loads in the IR (#90768)
shouldCastAtomicLoadInIR is a hack that should be removed. Simple
bitcasting of operations should be in the domain of ordinary type
legalization and does not need to be done in the IR.
This introduces a code quality regression due to the hack currently used
to avoid using 128-bit values in the case where the floating point value
is ultimately used as an integer. This would be avoidable if there were
always a legal 128-bit type (like v2i64). This is a pretty niche
situation so I assume it's not important.
I implemented about 85% of the work necessary to make v2i64 legal, but
it was taking too long and I lack the necessary familiarity with systemz
to complete it. I've pushed it here for someone to pick up:
https://github.com/arsenm/llvm-project/pull/new/systemz-legal-v2i64
Depends #90861
[RemoveDIs][Clang] Resolve DILocalVariables used by DbgRecords (#90882)
This patch fixes debug records in clang, by adding support for debug
records to the only remaining place that refers to DbgVariableIntrinsics
directly and does not handle DbgVariableRecords.
[DebugInfo] Make DISubprogram's hashing always produce the same result (#90770)
A DISubprogram's hashing algorithm takes into account its Scope. A Scope
can be a temporary though which can be replaced later on during
compilation. This means that the hashing algorithm for a DISubprogram
could produce a different hash before/after the Scope has changed. Fix
this by checking the Scope's linkage name instead, which should always
be the same.
rdar://127004707
