[libclang/python] Add deprecation warnings to CompletionChunk.isKind methods (#177854)
This adresses point 3 from
https://github.com/llvm/llvm-project/issues/156680.
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav at gmail.com>
[GlobalIsel] Enabling more rules for fp constant folding (#177902)
This PR extends GlobalISel to enable additional compile time constant
foldings
Resolves https://github.com/llvm/llvm-project/issues/86406
[LifetimeSafety] Add suggestion and inference for implicit this (#176703)
This PR implements support for automatically suggesting and inferring
`[[clang::lifetimebound]]` annotations for the implicit `this`.
The analysis now models the implicit this object as an implicit
parameter that carries a "placeholder loan" from the caller's scope. By
tracking this loan through the method body, the analysis can identify if
this reaches an escape point, such as a return statement.
Key Changes:
- Updated `PlaceholderLoan` to hold a union of `ParmVarDecl*` and
`CXXMethodDecl*`
- Extended `OriginManager` to handle `CXXThisExpr` and create a
dedicated origin list for the implicit this parameter
- Modified `FactsGenerator::issuePlaceholderLoans` to create a
placeholder loan for this at the entry of non-static member functions
- Updated `implicitObjectParamIsLifetimeBound` in
`LifetimeAnnotations.cpp` to check for the attribute on the method
[32 lines not shown]
[RISCV] Run combineOrToBitfieldInsert after DAG legalize (#177830)
Not combing `OR` into `QC.INSB(I)` before DAG legalization helps known
bits analysis to simplify the code if possible.
[include-cleaner] Update main-file checking in htmlreport generation
We updated how walkUsed decides if a location belongs to mainfile in
51ee583b1a02b6a4dce86dbe36af91ec60d45137 but forgot to update html
report generation.
[lldb] Fix error when running "memory region --all" repeatedly (#177176)
Due to some faulty logic, if you ran "memory region --all" twice, the
second time lldb would try to repeat the command. There's nothing to
repeat, so it failed with an error. It should treat each "--all" use as
starting from scratch.
The logic here was written in a confusing way, so I've refactored it to
first look at how many arguments there are (aka how many address
expressions there are) and then validate based on that.
For reasons unknown, I could not reproduce this issue using the API test
TestMemoryRegion.py. So I have added a shell test that I confirmed does
fail without this fix.
[AMDGPU][Test][AIX] use tr instead of sed for line split (#175557)
Test case is using sed command `sed 's/,/,\n/g'` to split a line.
On AIX that is not working with the AIX system's `sed`
AIX external BB fails from
https://lab.llvm.org/buildbot/#/builders/64/builds/6911
Here substitute:
`sed 's/,/,\n/g'`
with:
`tr ',' '\n'`
but because `tr` does not keeps the comma, also needed to change looked
for texts i.e. to remove the comma `,` from them since it is not needed
for the correctness.
Co-authored-by: Daniel Chen <cdchen at ca.ibm.com>
(cherry picked from commit 50703faab8a466adfea961636d439a61e5d26007)
[lldb][windows] switch to Python 3.11 for the non ARM64 release builds (#175796)
This patch is a follow up to
[RFC#89434](https://discourse.llvm.org/t/rfc-sync-python-versions-on-windows/89434).
Python 3.11 is the first official Python.org release to have an arm64
installer on Windows, which is why it's the version used to build the
toolchain on arm64 Windows. The x86 and x64 variants of the toolchain
both use Python 3.10 which can be confusing for users who get different
install dependencies based on their architectures.
This patch syncs all the required Pythons to install the toolchain, by
bumping the requirements to 3.11 for x86, x64 and arm64 Windows.
(cherry picked from commit 301c0d91b558a31a8d907b206070427b8eaa60dd)
[clang][modules] Read PCM validation timestamp earlier (#177062)
When building a module, the PCM file is always written first and then
the validation timestamp gets created. Clang needs to first read the
validation timestamp and only then read the PCM file. Otherwise, it
could read an out-of-date PCM file and then read the validation
timestamp for its new up-to-date version. This would erroneously skip
validation with `-fmodules-validate-once-per-build-session`. I'm not
concerned about multiple Clang instances seeing different filesystem
contents from each other within a single build session, since that would
break the assumption `-fmodules-validate-once-per-build-session` relies
on.
(cherry picked from commit ada79f4c2691ab6546d379a144377162fd4f5191)
[ARM] Count register copies when estimating function size (#175763)
`EstimateFunctionSizeInBytes`, in `ARMFrameLowering.cpp`, provides an
early estimate of the compiled size of a function, in a context that
wants to overestimate rather than underestimate.
In some cases it was underestimating severely, by over 20%. The
discrepancy was entirely accounted for by the fact that `COPY`
operations were not being counted at all, even though each one (or at
least each one that survives any post-regalloc optimizations) takes 2
bytes in Thumb or 4 in Arm. This could lead to a compile failure, if the
underestimated function size led frame lowering to not stack LR, but
later, `ARMConstantIslandsPass` needed to insert an intra-function
branch long enough to require a `bl` instruction, needing LR to have
been stacked.
The result of `EstimateFunctionSizeInBytes` was not directly available
for testing, so I added an `LLVM_DEBUG` at the end of the function. That
way, the test file doesn't need to try to make a >2048 byte function
[8 lines not shown]
[AArch64][Driver] Allow runtime detection to override default feaures.
Currently, most extensions controlled through -march and -mcpu options
are handled in a bitset of AArch64::ExtensionSet. However, extensions
detected at runtime for native compilation are handled in a separate
list of CPU features; once most of the parsing logic has run, the bitset
is converted to a list of features, added after the features detected at
runtime, and the resulting list is used from there on.
This has the downside that runtime-detected features are unable to
override default CPU extensions. For example, if a CPU enables +aes in
its processor definition, but aes is not found at runtime, the feature
currently remains enabled---even though unsupported---because default
features are enabled after the runtime logic attempts to disable them.
This patch inserts runtime-detected features directly into the extension
set such that these options can take precedence over extensions enabled
by default. The general parsing order for mcpu=native becomes:
1. CPU defaults;
[9 lines not shown]
[BranchFolding][WinEH] Do not remove EH pads (#176735)
If branch folding remoes an EH pad, we're left with a dangling reference
to it from the CxxUnwindMap. We could try to fix this up, but given that
this should be a rare situation, just leave the dead EH pad blocks
around.
Fixes https://github.com/llvm/llvm-project/issues/176421.
(cherry picked from commit 528bb2bedaa9e51c8078d41b977d266fa7d65ec7)
[X86][WinEH] Insert nop after unwinding inline assembly (#176393)
As discussed on https://github.com/llvm/llvm-project/pull/144745, insert
a nop after unwinding inline assembly, as it may end on a call.
While the change itself is trivial, I ended up having to do two
infrastructure changes:
* The unwind flag needs to be propagated to ExtraInfo of the
MachineInstr.
* The MachineInstr needs to be passed through to emitInlineAsmEnd(), and
the method needs to be non-const.
Fixes https://github.com/llvm/llvm-project/issues/157073.
(cherry picked from commit 792670a4003cba8636713916bed89a0b991fb32d)
[IRMover] Use signature for exact definition (#177381)
It is possible for optimizations to modify attributes on exact
definitions. In particular, DeadArgumentElimination may find that a
certain argument is dead, and replace arguments in calls with `poison`.
This requires dropping the `noundef` attribute on the argument.
When ThinLTO import is performed, the destination module already has a
declaration for the function, and the definition is not imported (e.g.
because it is noinline), we currently simply retain the original
declaration. This is incorrect if call with poison arguments were
imported, as the calls become immediate UB.
There was a previous attempt to address this in
https://reviews.llvm.org/D139209. What that patch did was to fix up the
attributes of the declaration after the fact, dropping UB implying
attributes that are not present on the definition. It was reverted
because it made an incorrect assumption that the signature between the
declaration and definition must match.
[9 lines not shown]
[AMDGPU][SILoadStoreOptimizer] Fix lds address operand offset (#176816)
The offset operand in GLOBAL_LOAD_ASYNC_TO_LDS_B128, for instance, is
added to both the lds and global address, but SILoadStoreOptimizer is
currently unaware of that. This PR inserts an add to counteract the
offset meant for the global address. This one add is better than not
doing the optimization at all, and having to insert 2 adds for each
global address calculation (with no offset).
```
; ENABLE-LABEL: name: promote_async_load_offset
; ENABLE: liveins: $ttmp7, $vgpr0, $sgpr0_sgpr1
; ENABLE-NEXT: {{ $}}
; ENABLE-NEXT: renamable $vgpr1 = V_LSHLREV_B32_e32 8, $vgpr0, implicit $exec
; ENABLE-NEXT: renamable $vgpr2, renamable $vcc_lo = V_ADD_CO_U32_e64 $vgpr0, 512, 0, implicit $exec
; ENABLE-NEXT: renamable $vgpr3, dead $sgpr_null = V_ADDC_U32_e64 0, killed $vgpr0, killed $vcc_lo, 0, implicit $exec
; ENABLE-NEXT: renamable $vgpr1 = disjoint V_OR_B32_e32 0, killed $vgpr1, implicit $exec
; ENABLE-NEXT: renamable $vgpr0 = V_ADD_U32_e32 256, $vgpr1, implicit $exec
; ENABLE-NEXT: GLOBAL_LOAD_ASYNC_TO_LDS_B128 killed $vgpr0, $vgpr2_vgpr3, -256, 0, implicit-def $asynccnt, implicit $exec, implicit $asynccnt :: (load store (s128), align 1, addrspace 3)
[18 lines not shown]
[clang][bytecode] Fix crash caused by overflow of Casting float number to integer (#177815)
Before this PR evaluation process will stop immediately regradless of
whether it's set to handle overflow,
this will prevent us getting value from stack, which leads to crash(with
or without assertion).
Closes #177751.
[clang][bytecode] Fix crash on discarded complex comparison (#177731)
Fixes llvm#176902: [clang][bytecode] crashes on ill-formed
_Static_assert comparing complex value
This patch resolves a crash in Clang's constant evaluation when handling
complex number comparisons in discarded expressions, such as those
involving short-circuiting logical operators. The crash occurred due to
unnecessary evaluation of the comparison in the experimental constant
interpreter.
The issue was originally observed and minimized in the following
example:
```cpp
#define EVAL(a, b) _Static_assert(a == b, "")
void foo() {
EVAL(; + 0, 1i);
[19 lines not shown]
[C++20] [Modules] Set ManglingContextDecl when we need to mangle a lambda but it's nullptr (#177899)
Close https://github.com/llvm/llvm-project/issues/177385
The root cause of the problem is, when we decide to mangle a lamdba in a
module interface while the ManglingContextDecl is nullptr, we didn't
update ManglingContextDecl. So that the following use of
ManglingContextDecl is an invalid value.
