[libunwind] Fix unwind_leaffunction test

It's possible for this test not to pass if the libc used does not provide
unwind info for raise. We can replace it with __builtin_cast, which can lead
to a SIGTRAP on x86_64 and a SIGILL on aarch64.

Using this alternative, a nop is needed before the __builtin_cast. This is
because libunwind incorrectly decrements pc, which can cause pc to jump into
the previous function and use the incorrect FDE.

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

[CFG] Handle calls with funclet bundle

When Control Flow Guard Check is inserted, funclet bundle was not checked. Therefore, it didn't generate code correctly when a target function has "funclet" bundle.

Reviewed By: rnk

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

[HWASan] Try 'google' prefixed apex directories in symbolizer.

Google-signed apexes appear on Android build servers' symbol files as
being under /apex/com.google.android.<foo>/. In reality, the apexes are
always installed as /apex/com.android.<foo>/ (note the lack of
'google'). In order for local symbolization under hwasan_symbolize to
work correctly, we also try the 'google' directory.

Reviewed By: eugenis

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

[AMDGPU] Fixed incomplete definitions in twoaddr-fma.mir. NFC.

[AMDGPU] Kill def when folding immediate in two-addr pass

Two-address pass works right before RA and if an immediate
was folded into an instruction there is nothing to remove
the dead def. We end up with something like:

v_mov_b32_e32 v14, 0xc1700000
v_mov_b32_e32 v14, 0x41200000
v_fmaak_f32 v51, s67, v19, 0xc1700000
v_fmaak_f32 v38, v51, v19, 0x4120000

The patch kills the dead move instruction right in the folding.

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

[DAG] PromoteIntRes_FunnelShift - rename shift Amount variable to Amt to prevent line overflow. NFC.

[funcattrs] Fix a bug in recently introduced writeonly argument inference

This fixes a bug in 740057d.  There's two ways to describe the issue:
* One caller hasn't yet proven nocapture on the argument.  Given that, the inference routine is responsible for bailing out on a potential capture.
* Even if we know the argument is nocapture, the access inference needs to traverse the exact set of users the capture tracking would (or exit conservatively).  Even if capture tracking can prove a store is non-capturing (e.g. to a local alloc which doesn't escape), we still need to track the copy of the pointer to see if it's later reloaded and accessed again.

Note that all the test changes except the newly added ones appear to be false negatives.  That is, cases where we could prove writeonly, but the current code isn't strong enough.  That's why I didn't spot this originally.

[IR][AutoUpgrade] Merge x86 mask load intrinsic upgrades. NFC.

Helps appease MSVC which is complaining about "fatal error C1061: compiler limit: blocks nested too deeply" - we already do the same thing for avx512.mask.store intrinsics.

This is only a stopgap solution until another else-if case needs adding - we really need to refactor this chain of ifs properly.

[LLDB] XFAIL on Arm/Linux minidebuginfo-set-and-hit-breakpoint.test

minidebuginfo-set-and-hit-breakpoint.test is failing on Arm/Linux most
probably due to an ill formed binary after removal of certain sections
from executable. I am marking it as XFAIL for further investigation.

[ARM] Separate ARM autoupgrade code into a separate function

Try to appease the microsoft compiler which is apparently running out of
if statements. Separate the new ARM code into a separate function to
keep it simpler.

[ARM] Replace if's with a switch, NFC

I'm not having a lot of luck with the microosft compiler recently. Maybe
this will help it with its errors:
llvm\lib\IR\AutoUpgrade.cpp(3726): fatal error C1061: compiler limit: blocks nested too deeply

If not, it's a good code cleanup anyway.

[libc] Fix invalid include for SqrtLongDouble.h

[gn build] Build with Fission on non-mac non-win when using lld

In release+sym builds (-O2 -g), reduces time to link `clang`
from 2.3s to 1.3s (-42%).

In debug builds (-g), reduces time to link `clang`
from 5.4s to 4.5s (-17.4%).

See the phab review for full `ministat` numbers.

In the CMake build this is opt-in via LLVM_USE_SPLIT_DWARF.
Since the GN build is targeted at developers, enabling it by default
seems like a better default setting here. (If it turns out to cause
problems, we can add an opt-out.)

Time to load the binary into gdb and to set a breakpoint is unchanged.
Time from `run` to hitting a breakpoint in `main` feel a bit faster
(~4s -> ~2s), but I dind't do a careful statistical anlysis for this.

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

[MemoryLocation] Move DSE intrinsic handling to MemoryLocation. (NFC)

Suggested in D114872.

[libc] Select FPUtils implementations via code instead of build

We want to simplify the build system and rely on code to do the implementation selection.
This is in preparation of adding a Bazel configuration (D114712).

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

[clang-tidy][docs][NFC] Improve documentation of bugprone-unhandled-exception-at-new

Reviewed By: aaron.ballman

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

[DebugInfo] Attempt to preserve more information during tail duplication

Prior to this patch, tail duplication handled debug info poorly -
specifically, debug instructions would be dropped instead of being set
undef, potentially extending the lifetimes of prior debug values that
should be killed. The pass was also very aggressive with dropping debug
info, dropping debug info even when the SSA value it referred to was
still present. This patch attempts to handle debug info more carefully,
checking to see whether each affected debug value can still be live,
setting it undef if not.

Reviewed By: jmorse

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

[ARM] Use v2i1 for MVE and CDE intrinsics

This adjusts all the MVE and CDE intrinsics now that v2i1 is a legal
type, to use a <2 x i1> as opposed to emulating the predicate with a
<4 x i1>. The v4i1 workarounds have been removed leaving the natural
v2i1 types, notably in vctp64 which now generates a v2i1 type.

AutoUpgrade code has been added to upgrade old IR, which needs to
convert the old v4i1 to a v2i1 be converting it back and forth to an
integer with arm.mve.v2i and arm.mve.i2v intrinsics. These should be
optimized away in the final assembly.

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

[libc] Fix bugs with negative and mixed normal/denormal inputs in hypot implementation.

Fix a bug with negative and mixed normal/denormal inputs in hypot implementation.

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

[PowerPC] Handle base load with reservation mnemonic

The Power ISA defined l[bhwdq]arx as both base and
extended mnemonics. The base mnemonic takes the EH
bit as an operand and the extended mnemonic omits
it, making it implicitly zero. The existing
implementation only handles the base mnemonic when
EH is 1 and internally produces a different
instruction. There are historical reasons for this.
This patch simply removes the limitation introduced
by this implementation that disallows the base
mnemonic with EH = 0 in the ASM parser.

This resolves an issue that prevented some files
in the Linux kernel from being built with
-fintegrated-as.

Also fix a crash if the value is not an integer immediate.

[TrivialDeadness] Introduce API separating two different usages

The earlier usage of wouldInstructionBeTriviallyDead is based on the
assumption that the use_count of that instruction being checked will be
zero. This patch separates the API into two different ones:

1. The strictly conservative one where the instruction is trivially dead iff the uses are dead.
2. The slightly relaxed form, where an instruction is dead along paths where it is not used.

The second form can be used in identifying instructions that are valid
to sink down to uses (D109917).

Reviewed-By: reames
Differential Revision: https://reviews.llvm.org/D114647

[lldb-vscode] Report supportsModulesRequest=true

The adapter does support `Modules` request, implemented in 39239f9.

Reviewed By: wallace

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

[OPENMP]Fix PR52117: Crash caused by target region inside of task construct.

Need to do the analysis of the captured expressions in the clauses.
Previously the compiler ignored them and it may lead to a compiler crash
trying to get the address of the mapped variables.

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

[InstSimplify] Add test case for logic 'or' fold; NFC

[mlir][linalg][bufferize][NFC] Map only tensors in BufferizationState

BufferizationState had map/lookup overloads for non-tensor values. This was necessary for IREE. There is now a better way to do this, so these overloads can be removed.

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

[ARM] Make MVE v2i1 predicates legal

MVE can treat v16i1, v8i1, v4i1 and v2i1 as different views onto the
same 16bit VPR.P0 register, with v2i1 holding two 8 bit values for the
two halves. This was never treated as a legal type in llvm in the past
as there are not many 64bit instructions and no 64bit compares. There
are a few instructions that could use it though, notably a VSELECT (as
it can handle any size using the underlying v16i8 VPSEL), AND/OR/XOR for
similar reasons, some gathers/scatter and long multiplies and VCTP64
instructions.

This patch goes through and makes v2i1 a legal type, handling all the
cases that fall out of that. It also makes VSELECT legal for v2i64 as a
side benefit. A lot of the codegen changes as a result - usually in way
that is a little better or a little worse, but still expensive. Costs
can change a little too in the process, again in a way that expensive
things remain expensive. A lot of the tests that changed are mainly to
ensure correctness - the code can hopefully be improved in the future
where it comes up in practice.

The intrinsics currently remain using the v4i1 they previously did to
emulate a v2i1. This will be changed in a followup patch but this one
was already large enough.

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

[AMDGPU] Add some more GFX10 test coverage

[fir] Add fir character builder

This patch adds the FIR builder to generate the numeric intrinsic
runtime call.

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

Reviewed By: rovka

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

Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>

[fir] Add fir derived type runtime builder

This patch adds the builder to generate derived type runtime API calls.

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

Reviewed By: rovka

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

Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>

[AMDGPU] Add some more GFX10 GlobalISel test coverage

[mlir][linalg][bufferize][NFC] Provide default implementation of getAliasingOpOperand

This simplifies op interface implementations.

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

[SelectionDAG] Add newline to a debug message

[MemoryLocation] Use None instead of {}. (NFC)

[libc][NFC] Fix typo in CMakeLists documentation

[mlir][NFC] Use const reference for loop variables.

[PowerPC] Add non-constant fcopysign f128 test coverage

As discussed on D114589 as the constant case gets affected by SimplifyDemandedBits a lot - the non-constant case currently falls back to copysignl libcalls

AMDGPU/GlobalISel: Add clamp combine

Add clamp combine. Source is fminnum(fmaxnum(Val, 0.0), 1.0) or
fmaxnum(fminnum(Val, 1.0), 0.0) or fmed3 intrinsic with 0.0 and
1.0 as two out of three operands.

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

AMDGPU/GlobalISel: Add floating point med3 combine

Add floating point version of med3 combine.
Source is fminnum(fmaxnum(Val, K0), K1) or fmaxnum(fminnum(Val, K1), K0)
where K0 and K1 are constants and K0 <= K1.

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

AMDGPU/GlobalISel: Do not fcanonicalize const splat padded with undef

Recognize constant splat padded with undef in isCanonicalized.
Fcanonicalize will be removed by RemoveFcanonicalize in post-legalizer
combiner. We will treat undef as value that will result in a splat
in clamp combine after regbankselect.

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

[mlir] support recursive type conversion of named LLVM structs

A previous commit added support for converting elemental types contained in
LLVM dialect types in case they were not compatible with the LLVM dialect. It
was missing support for named structs as they could be recursive, which was not
supported by the conversion infra. Now that it is, add support for converting
such named structs.

Depends On D113579

Reviewed By: wsmoses

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

[mlir][linalg][bufferize][NFC] Move FuncOp boundary bufferization to ModuleBufferization

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

[mlir][linalg][bufferize] Allow unbufferizable ops in input

Allow ops that are not bufferizable in the input IR. (Deactivated by default.)

bufferization::ToMemrefOp and bufferization::ToTensorOp are generated at the bufferization boundaries.

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

[RISCV][VP] Add RVV codegen for vp.select

Lower vp.select instrinsic to VSELECT_VL.

Reviewed By: rogfer01

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

[flang] Add missing LABEL in test. NFC

[fir] TargetRewrite: Rewrite fir.address_of(func)

Rewrite AddrOfOp if taking the address of a function.

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

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

[mlir][linalg][bufferize][NFC] Move BufferizationOptions to op interface

Also store a reference to BufferizationOptions in BufferizationState. This is in preparation of adding support for partial bufferization.

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

[fir] Add fircg.ext_embox conversion

Convert a fircg.ext_embox operation to LLVM IR dialect.
A fircg.ext_embox is converted to a sequence of operation that
create, allocate if needed, and populate a descriptor.

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

Reviewed By: kiranchandramohan

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

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>

[llvm-dwarfdump] Do not print preceding :: for local types

Reviewed By: dblaikie, jhenderson

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

[PowerPC] [Clang] Fix alignment adjustment of single-elemented float128

This does similar thing to 6b1341e, but fixes single element 128-bit
float type: `struct { long double x; }`.

Reviewed By: rjmccall

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

[Clang] Mutate bulitin names under IEEE128 on PPC64

Glibc 2.32 and newer uses these symbol names to support IEEE-754 128-bit
float. GCC transforms name of these builtins to align with Glibc header
behavior.

Since Clang doesn't have all GCC-compatible builtins implemented, this
patch only mutates the implemented part.

Note nexttoward is a special case (no nexttowardf128) so it's also
handled here.

Reviewed By: jsji

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

Fix typos in FPUtil README

[MemoryLocation] Move DSE's logic to new MemLoc::getForDest helper (NFC).

DSE has some extra logic to determine the write location of library
calls like str*cpy and str*cat. This patch moves the logic to a new
MemoryLocation:getForDest variant, which takes a call and TLI.

This patch should be NFC, because no other places take advantage of the
new helper yet.

Suggested by @reames post-commit 7eec832def571.

Reviewed By: nikic

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

[SCEV] Fix ValuesAtScopesUsers consistency

Fixes verification failure reported at:
https://reviews.llvm.org/rGc9f9be0381d1

The issue is that getSCEVAtScope() might compute a result without
inserting it in the ValuesAtScopes map in degenerate cases,
specifically if the ValuesAtScopes entry is invalidated during the
calculation. Arguably we should still insert the result if no
existing placeholder is found, but for now just tweak the logic
to only update ValuesAtScopesUsers if ValuesAtScopes is updated.

[mlir][Vector] Support 0-D vectors in `BitCastOp`

The implementation only allows to bit-cast between two 0-D vectors. We could
probably support casting from/to vectors like `vector<1xf32>`, but I wasn't
convinced that this would be important and it would require breaking the
invariant that `BitCastOp` works only on vectors with equal rank.

Reviewed By: nicolasvasilache

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

[mlir][Vector] Add some missing tests for `broadcast` and `splat`

Reviewed By: nicolasvasilache

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

[MemoryLocation] strcat/strncat/strcpy read/write after their args.

strcpy/strcat/strncat access memory starting from the passed in
pointers. Construct memory locations for their args using getAfter.

Discussed in D114872.

Reviewed By: reames

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

[clangd] IncludeCleaner: Do not require forward declarations of RecordDecls when definition is available

This makes IncludeCleaner more useful in the presense of a large number of
forward declarations. If the definition is already in the Translation Unit and
visible to the Main File, forward declarations have no effect.

The original patch D112707 was split in two: D114864 and this one.

Reviewed By: kadircet

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

tsan: disable munmap_invalid.cpp test on darwin

It failed on bots:
https://green.lab.llvm.org/green//job/clang-stage1-RA/25954/consoleFull#-1417328700a1ca8a51-895e-46c6-af87-ce24fa4cd561
and it  doesn't provide the test output.

Reviewed By: melver

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

[mlir][linalg][bufferize] Op interface implementation for Bufferization dialect ops

This change provides `BufferizableOpInterface` implementations for ops from the Bufferization dialects. These ops are needed at the bufferization boundaries for partial bufferization.

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

[flang] Return arrays in Transfer runtime with SIZE argument

In TRANSFER runtime the result was an array only if the MOLD was an array.
This is not in line with TRANSFER definition in 16.9.193 that rules that it
must also be an array if MOLD is scalar and SIZE if provided.

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

[TableGen][SelectionDAG] Use ComplexPattern type for non-leaf nodes

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. This addresses that
discrepancy. The test case is not representative of most real-world uses
but is sufficient to demonstrate inference is working.

Some of these uses also make use of ValueTypeByHwMode rather than
SimpleValueType and so the existing type inference is extended to
support that alongside the new type inference.

There are also currently various cases of using ComplexPatterns with an
untyped type, but only for non-leaf nodes. For compatibility this is
permitted, and uses the old behaviour of not inferring for non-leaf
nodes, but the existing logic is still used for leaf values. This
remaining discrepancy should eventually be eliminated, either by
removing all such uses of untyped so the special case goes away (I
imagine Any, or a more specific type in certain cases, would be
perfectly sufficient), or by copying it to the leaf value case so
they're consistent with one another if this is something that does need
to keep being supported.

All non-experimental targets have been verified to produce bit-for-bit
identical TableGen output with this change applied.

Reviewed By: kparzysz

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

[AArch64][NFC] Alter ComplexPattern types to be consistent with their uses

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. Fixing that
discrepancy is something I intend to upstream as a subsequent review.

AArch64 currently has several ComplexPatterns that are used in contexts
where they're expected to be an iPTR. The cases that lead to type
contradictions are separated out in D108759, but there are additional
differences to the TableGen output when using my locally-patched
TableGen. None of these appear to matter, at least for passing all the
CodeGen tests, but it's safer to avoid such changes (and similar changes
were causing issues on some AMDGPU tests, causing failures to select).
Changing these additional ComplexPatterns to use iPTR rather than i64
ensures that the TableGen output remains bit-for-bit identical (compared
to without having this patch and my TableGen patch, as well as the
intermediate state of having this patch but not my TableGen patch), and
more accurately captures the higher-level meaning of these patterns.

Reviewed By: david-arm

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

[AMDGPU][NFC] Alter ComplexPattern types to be consistent with their uses

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. Fixing that
discrepancy is something I intend to upstream as a subsequent review.

AMDGPU currently has several ComplexPatterns that are used in contexts
where they're expected to be an iPTR, and where using an iPTR instead of
a fixed-width integer type matters. With my locally-patched TableGen,
none of these mismatches result in type contradictions, but do change
the patterns and cause various failures to select. These changes to the
ComplexPatterns' types reflect how they are actually used, result in
bit-for-bit identical TableGen output (without my local TableGen patch),
and ensure that with improved type inference AMDGPU's backend will
continue to work.

Reviewed By: arsenm

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

[AArch64][NFC] Fix ComplexPattern types conflicting with uses

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. Fixing that
discrepancy is something I intend to upstream as a subsequent review,
but these are all the type conflicts found (all legitimate) by my
locally-patched TableGen.

Reviewed By: paulwalker-arm

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

[NFC] move GNUELFDumper::printEnum() into a common header for reuse.

Summary:
This is a NFC patch moving the GNUELFDumper<ELFT>::printEnum()
 function from ELFDumper into ScopedPrinter.h for reuse.

Reviewed By: jhenderson

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

[Coroutines] Handle InvokeInst in SalvageDebugInfo

Since coroutine would be splitted into pieces, compiler would move the
dbg.declare intrinsic after the Storage is created to make sure the
corresponding dbg instruction is still available aftet splitted.
However, it would be problematic if the storage instruction is an
InvokeInst, which is a terminator. We couldn't move instruction after an
InvokeInst. This patch tries to move the dbg.declare intrinsic in the
normal destination of the InvokeInst. It should make sense due to the
Storage should be invalid in exception path.

[clangd] Show parameters for construct.

Show parameters for construct.

Reviewed By: kadircet

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

[lldb] add fallback for LLDB_PYTHON_RELATIVE_PATH

Some pythons are configured to set platlib somewhere outside of their
sys.prefix.   It's important that we at least use some reasonable
default for LLDB_PYTHON_RELATIVE_PATH even in that case, because
even if the user overrides it on the cmake invocation, cmake will
still be called without the override in order to build tablegen.

Reviewed By: JDevlieghere, clayborg

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

[ASan] Changed intrisic implemenation to use PLT safe registers.

Changed registers to R10 and R11 because PLT resolution clobbers them. Also changed the implementation to use R11 instead of RCX, which saves a push/pop.

Reviewed By: vitalybuka

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

[llvm][Inline] Add FunctionSimplificationPipeline to module inliner pipeline

The FunctionSimplificationPipeline could effectively reduce the size of .text section when module inliner is enabled.

Reviewed By: kazu

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

[gn build] Port aba8f320cc13

[gn build] Port 2d9efcfeec24

Simplify logic to identify dyld_sim in Simulator debugging on macos

When debugging a Simulator process on macOS (e.g. the iPhone simulator),
the process will have both a dyld, and a dyld_sim present.  The dyld_sim
is an iOS Simulator binary.  The dyld is a macOS binary.  Both are
MH_DYLINKER filetypes.  lldb needs to identify & set a breakpoint in
dyld, so it has to distinguish between these two.

Previously lldb was checking if the inferior target was x86 (indicating
macOS) and the OS of the MH_DYLINKER binary was iOS/watchOS/etc -- if
so, then this is dyld_sim and we should ignore it.  Now with arm64
macOS systems, this check was invalid, and we would set our breakpoint
for new binaries being loaded in dyld_sim, causing binary loading to
be missed by lldb.

This patch uses the Target's ArchSpec triple environment, to see if
this process is a simulator process.  If this is a Simulator process,
then we only recognize a MH_DYLINKER binary with OS type macOS as
being dyld.

This patch also removes some code that handled pre-2016 era debugservers
which didn't give us the OS type for each binary.  This was only being
used on macOS, where we don't need to handle the presence of very old
debugservers.

Differential Revision: https://reviews.llvm.org/D115001
rdar://85907839

[gn build] (manually) port 9c4d194f44c4 better

[lsan] Deflake fork_and_leak test

[gn build] (manually) port 9c4d194f44c4

[libc++][ranges] Implement [special.mem.concepts].

Implement the exposition-only concepts specified in
`[special.mem.concepts]`. These are all thin wrappers over other
concepts.

Reviewed By: #libc, Quuxplusone, ldionne

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

[CSSPGO] Turn on Profi by default

As titled.

Reviewed By: wenlei, wlei

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

Using make_unique instead of `new` (NFC)

Fix a clang-tidy warning.

[Bazel] Set the right default for LLVM_WINDOWS_PREFER_FORWARD_SLASH on Windows

This cmake configure option was added in
df0ba47c36f6bd0865e3286853b76d37e037c2d7, and was ported to
Bazel in 7d323dc7738e3152c4bd54a23ac27554bfbbf583.

However, the setting chosen in Bazel seems accidental, not necessarily
intentional.

LLVM_WINDOWS_PREFER_FORWARD_SLASH has no effect on Unix, and on
Windows, setting it to 0 is the default, which gets the same behaviour
as before. Setting it to 1 enables new experimental behaviours
(which is enabled by default on MinGW targets only).

As I don't see any explicit intent to opt in to the new experimental
behaviour, I believe the current configuration in bazel was a
mistake.

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

[clang][Darwin] Remove old lld implementation handling

This now assumes that for the darwin driver any lld is the "new" macho
lld implementation.

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

[bazel] Update static analyzer unit test deps for clangTesting

Run update_test_checks.py on test cases.

In this way, each instruction has a line, and diffs will be more clear.

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

[Bazel] Add LLVM_ENABLE_CURL to Bazel llvm-config.h.cmake for e0b259f2

[CostModel][AMDGPU] Fix instructions costs estimation for vector types.

1. Fixed vector instructions costs estimations incosistency - removed different
   logic for "not simple types" since it biases costs for these types.
2. Fixed legalization penalty for vectors too big for the target: changed from
   overwrite default legalization cost value estimation to added penalty.
3. Fixed few typos in tests.

Reviewed By: rampitec

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

Include extra input contents on this test so we can see why lldb-arm-ubuntu buildbot is failing.

Only lldb-arm-ubuntu is failing after https://reviews.llvm.org/D114288 and there isn't enough input context to see why this is failing. It works on x86_64 linux just fine.

[mlir][ods] update attr/type def format docs

[clang-tidy][objc] Finds and fixes improper usages of XCTAssertEquals and XCTAssertNotEquals.

Using XCTAssertEqual on NSString* objects is almost always  wrong.

Unfortunately, we have seen a lot of tests doing this and reyling on pointer equality for strings with the same values (which happens to work sometimes - depending on the linker, but this assumption is not guaranteed by the language)

These fixes would make tests less brittle.

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

[analyzer]Skip unstable CSA tests failing on several platforms

Clang static analyzer uses bitwidth to infer the integer value type, that is, any 32-bit integer is considered of type `int`, and any 64-bit integer is considered of type `long`. This isn't always true, for instance, in ILP32 (e.g., 32-bit AIX), 32-bit could be `long`, and in LP64 (e.g., 64-bit wasm64), 64-bit could be `long long`.

Reviewed By: steakhal

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

[ELF][PPC32] Make R_PPC32_PLTREL retain .got

PLT usage needs the first 12 bytes of the .got section. We need to keep .got and
DT_GOT_PPC even if .got/_GLOBAL_OFFSET_TABLE_ are not referenced (large PIC code
may only reference .got2), which is the case in OpenBSD's ld.so, leading
to a misleading error, "unsupported insecure BSS PLT object".

Fix this by adding R_PPC32_PLTREL to the list of hasGotOffRel.

Reviewed By: MaskRay

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

AMDGPU: Sanitized functions require implicit arguments

Do not infer no-amdgpu-implicitarg-ptr for sanitized functions. If a
function is explicitly marked amdgpu-no-implicitarg-ptr and
sanitize_address, infer that it is required.

[MLIR] Use a shared uniquer for affine maps and integer sets.

Affine maps and integer sets previously relied on a single lock for creating unique instances. In a multi-threaded setting, this lock becomes a contention point. This commit updates AffineMap and IntegerSet to use StorageUniquer instead. StorageUniquer internally uses sharded locks and thread-local caches to reduce contention. It is already used for affine expressions, types and attributes. On my local machine, this gives me a 5X speedup for an application that manipulates a lot of affine maps and integer sets.

This commit also removes the integer set uniquer threshold. The threshold was used to avoid adding integer sets with a lot of constraints to the hash_map containing unique instances, but the constraints and the integer set were still allocated in the same allocator and never freed, thus not saving any space expect for the hash-map entry.

Reviewed By: rriddle

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

[NFC][sanitizer] Remove SetSoftRssLimitExceededCallback

According comments on D44404, something like that was the goal.

Reviewed By: morehouse, kstoimenov

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

[NFC][sanitizer] Reorder functions in cpp file

libcxx pretty printers: remove non-lazy_string fallback

This has been supported on gdb for something like ~10 years, so doesn't
seem necessary to carry a fallback.

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

[TLI checker] Follow good practice with -COUNT directives

FileCheck's -COUNT suffix doesn't fail if there are more matches
than you asked for, so it's good practice to put a -NOT after.

[clang-tidy] Allow disabling support for NOLINTBEGIN/NOLINTEND blocks.

This patch parameterizes the clang-tidy diagnostic consumer with a boolean that
controls whether to honor NOLINTBEGIN/NOLINTEND blocks. The current support for
scanning these blocks is very costly -- O(n*m) in the size of files (n) and
number of diagnostics found (m), with a large constant factor.  So, the patch
allows clients to disable it.

Future patches should make the feature more efficient, but this will mitigate in
the interim.

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

[MLIR][FlatAffineConstraints] Remove duplicate divisions while merging local ids

This patch implements detecting duplicate local identifiers by extracting their
division representation while merging local identifiers.

For example, given the FACs A, B:

```
A: (x, y)[s0] : (exists d0 = [x / 4], d1 = [y / 4]: d0 <= s0, d1 <= s0, x + y >= 2)
B: (x, y)[s0] : (exists d0 = [x / 4], d1 = [y / 4]: d0 <= s0, d1 <= s0, x + y >= 5)
```

The intersection of A and B without this patch would lead to the following FAC:

```
(x, y)[s0] : (exists d0 = [x / 4], d1 = [y / 4], d2 = [x / 4], d3 = [x / 4]: d0 <= s0, d1 <= s0, d2 <= s0, d3 <= s0, x + y >= 2, x + y >= 5)
```

after this patch, merging of local ids will detect that `d0 = d2` and `d1 = d3`,
and the intersection of these two FACs will be (after removing duplicate constraints):

```
(x, y)[s0] : (exists d0 = [x / 4], d1 = [y / 4] : d0 <= s0, d1 <= s0, x + y >= 2, x + y >= 5)
```

This reduces the number of constraints by 2 (constraints) + 4 (2 constraints for each extra division) for this case.

This is used to reduce the output size representation of operations like
PresburgerSet::subtract, PresburgerSet::intersect which require merging local
variables.

Reviewed By: arjunp, bondhugula

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

Revert changes that should have been sent as a patch

Revert changes that were meant to be sent as a single commit with
summary for the differential review, but were accidently sent directly.

This reverts commit 3bc5353fc6f291d6ac12c256600b5b05d7de8f74.

[OPENMP]Fix PR50733: unexpected final value of list-item in linear clause in loop construct.

Currently the last value of linear is calculated as var = init + num_iters * step.
Replaced it with var = var_priv, i.e. original variable gets the value
of the last private copy.

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