This updates the Bazel configuration for
https://github.com/llvm/llvm-project/commit/070315d04c6b which moved
`LLVM_SUPPORT_XCODE_SIGNPOSTS` from llvm-config.h.cmake to
config.h.cmake.

Also adds a comment for `HAVE_PROC_PID_RUSAGE`, that I spotted was
missing.

Differential Revision: https://reviews.llvm.org/D111569

Implement P2401 which adds a `noexcept` specification to
`std::exchange`. Treated as a defect fix which is the motivation for
applying this change to all standards mode rather than just C++23 or
later as the paper suggests.

Reviewed By: Quuxplusone, Mordante, #libc

Differential Revision: https://reviews.llvm.org/D111481

Implement P2251 which requires `span` and `basic_string_view` to be
trivially copyable. They already are - this just adds tests to bind that
behavior.

Reviewed By: ldionne, Quuxplusone, Mordante, #libc

Differential Revision: https://reviews.llvm.org/D111197

This reverts commits f9aba9a5 and
035217ff.

As explained in the original commit message, this didn't have the
intended effect of improving the common LLDB use case, but still
provided a marginal improvement for the places where LLDB creates a
scoped time with a string literal.

The reason for the revert is that this change pulls in the os/signpost.h
header in Signposts.h. The former transitively includes loader.h, which
contains a series of macro defines that conflict with MachO.h. There are
ways to work around that, but Adrian and I concluded that  none of them
are worth the trade-off in complicating Signposts.h even further.

Add explicit documentation for a couple of cases where the Fortran
standard has been observed to be ambiguous or nonspecific and we've
had to choose the behavior of the implementation from some possible
alternatives (and may be distinct from other implementations).

Differential Revision: https://reviews.llvm.org/D111446

Reducing the number of iterations in that test with D111342 helped,
but the failure still occured flakily when the test is ran as part
of a large test suite.

Reducing further the number of iterations might not be good enough,
so we will skip the test if the `max_map_count` variable can be
read, and if lower than a given threshold.

Differential Revision: https://reviews.llvm.org/D111465

These instructions should allow src0 to be a literal with the same
value as the mandatory other literal. Enable it by introducing an
operand that defers adding its value to the MI when decoding till
the mandatory literal is parsed.

Reviewed By: dp, foad

Differential Revision: https://reviews.llvm.org/D111067

Change-Id: I22b0ae0d35bad17b6f976808e48bffe9a6af70b7

Missed in D110451.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D111472

Mostly copied from opt.cpp.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D111466

As a brief reminder, an "exit count" is the number of times the backedge executes before some event. It can be zero if we exit before the backedge is reached. A "trip count" is the number of times the loop header is entered if we branch into the loop. In general, TC = BTC + 1 and thus a zero trip count is ill defined

There is a cornercases which we don't handle well. Let's assume i8 for our examples to keep things simple. If BTC = 255, then the correct trip count is 256. However, 256 is not representable in i8.

In theory, code which needs to reason about trip counts is responsible for checking for this cornercase, and either bailing out, or handling it correctly. Historically, we don't have a great track record about actually doing so.

When reviewing D109676, I found myself asking a basic question. Was there any good reason to preserve the current wrap-to-zero behavior when converting from backedge taken counts to trip counts? After reviewing existing code, I could not find a single case which appears to correctly and precisely handle the overflow case.

This patch changes the default behavior to extend instead of wrap. That is, if the result might be 256, we return a value of i9 type to ensure we interpret the count correctly. I did leave the legacy behavior as an option since a) loop-flatten stops triggering if I extend due to weirdly specific pattern matching I didn't understand and b) we could reasonably use the mode if we'd externally established a lack of overflow.

I want to emphasize that this change is *not* NFC. There are two call sites (one in ScalarEvolution.cpp, one in LoopCacheAnalysis.cpp) which are switched to the extend semantics. The former appears imprecise (but correct) for a constant 255 BTC. The later appears incorrect, though I don't have a test case.

Differential Revision: https://reviews.llvm.org/D110587

The IR intrinsics use ImmArg for the policy operand so this needs to be enforced as a constant in the frontend.

Differential Revision: https://reviews.llvm.org/D110779

I think D79300 has fixed the D51892 (`__i686.get_pc_thunk.bx`) issue, so
we can bring back rL330869.
D79300 says `would error undefined symbol instead of the more relevant discarded section`
but it doesn't reproduce now.

This avoids a quirk in `isUndefWeak()`.

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D111365

armv9-a, armv9.1-a and armv9.2-a can be targeted using the -march option
both in ARM and AArch64.

 - Armv9-A maps to Armv8.5-A.
 - Armv9.1-A maps to Armv8.6-A.
 - Armv9.2-A maps to Armv8.7-A.
 - The SVE2 extension is enabled by default on these architectures.
 - The cryptographic extensions are disabled by default on these
 architectures.

The Armv9-A architecture is described in the Arm® Architecture Reference
Manual Supplement Armv9, for Armv9-A architecture profile
(https://developer.arm.com/documentation/ddi0608/latest).

Reviewed By: SjoerdMeijer

Differential Revision: https://reviews.llvm.org/D109517

Adds LLVMOrcCreateStaticLibrarySearchGeneratorForPath and
LLVMOrcCreateDynamicLibrarySearchGeneratorForPath functions to create generators
for static and dynamic libraries.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D108535

Aligned allocation routines added.
Fortran interfaces added for all allocation routines.

Differential Revision: https://reviews.llvm.org/D110923

https://bugs.llvm.org/show_bug.cgi?id=27506
https://bugs.llvm.org/show_bug.cgi?id=31652
https://bugs.llvm.org/show_bug.cgi?id=51043

Problems with SimpleLoopUnswitch cause the bug reports above.

```
while (...) {
  if (C) { A }
  else   { B }
}
Into:

C' = freeze(C)
if (C') {
  while (...) { A }
} else {
  while (...) { B }
}
```
This problem can be solved by adding a freeze on hoisted branches(above transform) and has been solved by D29015.
However, D29015 is now reverted by performance regression(https://github.com/llvm/llvm-project/commit/2b5a8976514de326bb84f0913d9d451089c11d22)

It is not the first time that an added freeze has caused performance regression.
SimplifyCFG also had a problem with UB caused by branching-on-undef, which was solved by adding freeze to the branching condition. (D104569)
Performance regression occurred in D104569, and patches such as D105344 and D105392 were written to minimize it.

This patch will correct the SimpleLoopUnswitch as D104569 handles the SimplyCFG while minimizing performance loss by introducing patches like D105344 and D105392(This patch was rebased with the author's permission)

Reviewed By: reames

Differential Revision: https://reviews.llvm.org/D106041

Until now, we only had documentation oriented towards developers of the
bindings. Provide some documentation for users of the bindings that don't want
or need to understand the inner workings.

Reviewed By: nicolasvasilache

Differential Revision: https://reviews.llvm.org/D111540

This adds support for the MSVC spelling of the pragma in -fms-extensions
mode.

Differential revision: https://reviews.llvm.org/D111440

Add an overload of DynamicRegisterInfo::SetRegisterInfo() that accepts
a std::vector<Register> as an argument.  This moves the conversion
from DRI::Register to RegisterInfo directly into DynamicRegisterInfo,
and avoids the necessity of creating fully-compatible intermediate
RegisterInfo instances.

While the new method could technically reuse AddRegister(), the ultimate
goal is to replace AddRegister() with SetRegisterInfo() entirely.

Differential Revision: https://reviews.llvm.org/D111435

Create pseudo-registers on the AArch64 target if they are not provided
by the remote server. This is the case for gdbserver. The created
registers are:

- 32-bit wN partials for 64-bit xN registers
- double precision floating-point dN registers (overlapping with vN)
- single precision floating-point sN registers (overlapping with vN)

Differential Revision: https://reviews.llvm.org/D109876

Move DynamicRegisterInfo::AddSupplementaryRegister() into a standalone
function working on std::vector<DynamicRegisterInfo::Register>.

Differential Revision: https://reviews.llvm.org/D111295

Call ABI::AugmentRegisterInfo() once with a vector of all defined
registers rather than calling it for every individual register.  Move
and rename RemoteRegisterInfo from gdb-remote to
DynamicRegisterInfo::Register, and use this class when augmenting
registers.

Differential Revision: https://reviews.llvm.org/D111142

The Object library currently has three identical functions that translate a
Twine into a parser error. Until recently these functions have coexisted
peacefully, but since D110320 Clang with enabled modules is now diagnosing that
we have several definitions of `createError` in Object.

This patch just merges them all and puts them into Object's `Error.h` where the
error code for `parse_failed` is also defined which seems cleaner and unbreaks
the bots.

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D111541

Add rewrite patterns for fir.convert op canonicalization.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: kiranchandramohan

Differential Revision: https://reviews.llvm.org/D111537



Co-authored-by: Valentin Clement <clementval@gmail.com>

[X86][AVX] Ensure we retain zero elements in select(pshufb,pshufb) -> or(pshufb,pshufb) fold (PR52122)

The select(pshufb,pshufb) -> or(pshufb,pshufb) fold uses getConstVector to create the refreshed pshufb masks, which treats all negative indices as undef.

PR52122 shows that if we were selecting an element that the PSHUFB has set to zero we must set it back to 0x80 when we recreate the PSHUFB mask and not just leave it as SM_SentinelZero

Clean up InitFIR.h file.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: kiranchandramohan

Differential Revision: https://reviews.llvm.org/D111539



Co-authored-by: Valentin Clement <clementval@gmail.com>

D68422 introduced `ParsedDWARFTypeAttributes` which encapsulated attribute
parsing and storage into its own small struct. This patch is doing the same for
the member type attribute parsing. One utility class is parsing normal member
attributes and the other is parsing the dedicated Objective-C property
attributes.

Right now the patch just makes the `ParseSingleMember` function a bit shorter,
but the bigger benefit is that we can now split up the function into Objective-C
property parsing and parsing of normal members (struct/class members and
Objective-C ivars). The only shared code between those two parsing logic is the
normal member attribute parsing.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D111494

I noticed that we had this case in our internal testsuite but couldn't find it in LLD's tests.

This adds that case.

Differential Revision: https://reviews.llvm.org/D110716

Rewrite the register reading/writing tests to use explicit qRegisterInfo
packets rather than relying on ARM registers being hardcoded in LLDB.
While at it, use x86_64 for tests -- since it was easier for me to get
the register lists from that architecture.

Differential Revision: https://reviews.llvm.org/D111496

Update .clang-tidy file with the value used in fir-dev.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: rovka

Differential Revision: https://reviews.llvm.org/D111525



Co-authored-by: Valentin Clement <clementval@gmail.com>

This patch adds a new abstract class for frontend actions:
`PrescanAndSemaDebugAction`. It's almost identical to
`PrescanAndSemaAction`, but in the presence of semantic errors it does
not skip the corresponding `ExecuteAction` specialisation. Instead, it
runs it as if there were no semantic errors. This class is for developer
actions only (i.e.  front-end driver options).

The new behaviour does not affect the return code from `flang-new -fc1`
when the input file is semantically incorrect. The return code is
inferred from the number of driver diagnostics generated in
`CompilerInstance::ExecuteAction` and this patch does not change that.
More specifically, the semantic errors are still reported and hence the
driver is able to correctly report that the compilation has failed (with
a non-zero return code).

This new base class is meant for debug actions only and
`DebugDumpAllAction` is updated to demonstrate the new behaviour. With
this change, `flang-new -fc1 -fdebug-dump-all` dumps the parse tree and
symbols for all input files, regardless of whether any semantic errors
were found.

This patch addresses https://bugs.llvm.org/show_bug.cgi?id=52097.

Differential Revision: https://reviews.llvm.org/D111308