This patch adds two flags to be supported for the new runtime. The flags
are `-fopenmp-assume-threads-oversubscription` and
-fopenmp-assume-teams-oversubscription`. These add global values that
can be checked by the work sharing runtime functions to make better
judgements about how to distribute work between the threads.

Reviewed By: jdoerfert

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

For NVPTX, `printf` can be used just with a function declaration. For AMDGCN, an
function definition is added, but it simply returns.

Reviewed By: jdoerfert

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

The shift libcalls have a shift amount parameter of MVT::i32, but
sometimes ExpandIntRes_Shift may be called with a node whose
second operand is a type that is larger than that. This leads to
an ABI mismatch, and for example causes a spurious zeroing of
a register in RV32 for 64-bit shifts. Note that at present regular
shift intstructions already have their shift amount operand adapted
at SelectionDAGBuilder::visitShift time, and funnelled shifts bypass that.

Reviewed By: craig.topper

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

Reviewed By: craig.topper

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

Reviewed By: craig.topper

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

We need to synchronize the threads *before* we destroy the RAII objects
that hold the old values and not after to avoid threads executing the
parallel region but seeing an inconsistent state.

Reviewed By: tianshilei1992

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

before:
00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00
Shadow map of [0x211000000005, 0x21100000012e), 297 bytes:
now:
0x2f60d213ac10[0x7f60d213ac10]  00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00
Shadow map [0x211000000005, 0x21100000012e) of [0x711000000005, 0x711000000135), 297 bytes:

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

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

When have ObjCInterfaceDecl with the same name in 2 different modules,
hitting the assertion

> Assertion failed: (Index < RL->getFieldCount() && "Ivar is not inside record layout!"),
> function lookupFieldBitOffset, file llvm-project/clang/lib/AST/RecordLayoutBuilder.cpp, line 3434.

on accessing an ivar inside a method. The assertion happens because
ivar belongs to one module while its containing interface belongs to
another module and then we fail to find the ivar inside the containing
interface. We already keep a single ObjCInterfaceDecl definition in
redecleration chain and in this case containing interface was correct.
The issue is with ObjCIvarDecl. IVar decl for IRGen is taken from
ObjCIvarRefExpr that is created in `Sema::BuildIvarRefExpr` using ivar
decl returned from `Sema::LookupIvarInObjCMethod`. And ivar lookup
returns a wrong decl because basically we take the first ObjCIvarDecl
found in `ASTReader::FindExternalVisibleDeclsByName` (called by
`DeclContext::lookup`). And in `ASTReader.Lookups` lookup table for a
wrong module comes first because `ASTReader::finishPendingActions`
processes `PendingUpdateRecords` in reverse order and the first
encountered ObjCIvarDecl will end up the last in `ASTReader.Lookups`.

Fix by merging ObjCIvarDecl from different modules correctly and by
using a canonical one in IRGen.

rdar://82854574

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

We want to use this tool in our build.

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

Currently Affine LICM checks iterOperands and does not hoist out any
instruction containing iterOperands. We should check iterArgs instead.

Reviewed By: bondhugula

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

JSON crashlogs have an optional field named reportNotes that contains
any potential errors encountered by the crash reporter when generating
the crashlog. Parse and display them in LLDB.

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

Gracefully deal with JSON crashlogs that don't have thread state
available and print an error saying as much: "No thread state (register
information) available".

rdar://83955858

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

This field only exists if the directory exists on the machine running
the test. It likely exists for most Intel macOS users because of
homebrew, but doesn't exist on some of the CI machines. This
unfortunately makes this test a bit less strict.

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

A [[ https://reviews.llvm.org/rGf6fa95b77f33c3690e4201e505cb8dce1433abd9 | recent commit  ]] removed `<string>` from `ErrorHandling.h`. The removal caused `<string>` to be no longer included for `llvm/tools/llvm-cxxdump/Error.cpp` which uses the string type.

This patch adds `<string>` to `llvm/tools/llvm-cxxdump/Error.cpp`.

Reviewed By: jsji

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

Using uselistorders is fairly niche, it shouldn't be on by default and mostly just clutters the output.

Reviewed By: jamieschmeiser

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

When we recently started using DYLD_LIBRARY_PATH to run the test suite
on the Apple/System configuration of the library, the -fno-exceptions
variant started failing.

It started failing because under that configuration, libc++abi.dylib
doesn't provide support for exceptions. For example, it doesn't provide
some symbols such as ___gxx_personality_v0. Now, the problem is that
when the test suite is run with DYLD_LIBRARY_PATH, /usr/lib/libobjc.dylib
uses the just-built libc++abi.dylib, which doesn't support exceptions,
and we end up with an unresolved reference to ___gxx_personality_v0.

Previously, using -Wl,-rpath,path/to/lib, we would be loading both
/usr/lib/libc++abi.dylib and <just-built>/lib/libc++abi.dylib.
/usr/lib/libobjc.dylib would use the system libc++abi.dylib, which
contains support for exceptions, and the tests would be using the
just-built one, which doesn't.

Disentangling that led me to believe that we shouldn't try to test this
configuration where libc++/libc++abi are built as system libraries, but
where they don't support exceptions, since that just doesn't make any
sense. Doing so is like trying to build libc++/libc++abi and test it as
a system library after performing an ABI break -- of course nothing is
going to work.

For that reason, I am removing this configuration. Note that we could
still test the library on macOS without exceptions if we wanted, only
we wouldn't be building it as a system library. This patch doesn't add
that because we already have a -fno-exceptions CI job on Linux.

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

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

This reverts commit a625fd26.

Round 3: The scudo test was addressed in
6727832c.

For some transformations like hot-cold split or coro split, it can outline its part of function ranges. Since sample loader is the early stage of backend and no split happens at that time, compiler can't recognize those function, so in llvm-profgen we should attribute the sample to the original function. This is already done for the body range samples since we use the symbols from dwarf which is created before the split.

But for branch samples, the call from master function to its outlined function is actually not a call to the original function, we shouldn't add head/callsie samples for it. So instead of dwarf symbol, we use the symbols from symbol table and ignore those functions with special suffixes(like `.cold` ,`.resume`) for accumulating the callsite/head samples.

Reviewed By: hoy, wenlei

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

`ScudoWrappersCppTest.AllocAfterFork` was failing obscurely sometimes.
Someone pointed us to Linux's `vm.max_map_count` that can be
significantly lower on some machines than others. It turned out that
on a machine with that setting set to 65530, some `ENOMEM` errors
would occur with `mmap` & `mprotect` during that specific test.

Reducing the number of times we fork, and the maximum size allocated
during that test makes it pass on those machines.

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

This change fixes a bug where the compiler generates a prologue_end
for line 0 locs. That is because line 0 is not associated with any
source location, so there should not be a prolgoue_end at a location
that doesn't correspond to a source location.

There were some LLVM tests that were explicitly checking for line 0
prologue_end's as well since I believe that to be incorrect, I had to
change those tests as well.

Patch by Shubham Rastogi!

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

This patch adds support for Swift compiler producer strings to DWARFUnit.

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

This will simplify removing id proposed by @dvyukov on D111183
Also now we have more flexiliby for traces compressio they
are not interleaving with uncompressable headers.

Depends on D111256.

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

This way is easier to track memory usage and do other
incremental refactorings.

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

Bit positions for the intrinsics IBCLR and IBSET and shift counts
for the intrinsics ISHFT/SHIFTA/SHIFTL/SHIFTR should be validated
when folding.

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

Updating the MachineDominatorTree is easy since SILowerControlFlow only
splits and removes basic blocks. This should save a bit of compile time
because previously we would recompute the dominator tree from scratch
after this pass.

Another reason for doing this is that SILowerControlFlow preserves
LiveIntervals which transitively requires MachineDominatorTree. I think
that means that SILowerControlFlow is obliged to preserve
MachineDominatorTree too as explained here:
https://lists.llvm.org/pipermail/llvm-dev/2020-November/146923.html
although it does not seem to have caused any problems in practice yet.

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

In a couple of places machine verification was disabled for no apparent
reason, probably just because an "addPass(..., false)" line was cut and
pasted from elsewhere.

After this patch the only remaining place where machine verification is
disabled in the generic TargetPassConfig code, is after addPreEmitPass.

DecompGEP.Base and UnderlyingV are currently always the same.
However, logically DecompGEP.Base is the right value to use here,
because the decomposed offset is relative to that base.

[ARC] ARCRegisterInfo cleanup prior to adding core register pairs (ARC32) and 64-bit core registers (ARC64)

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

Some subprojects like compiler-rt define the `darwin` feature in their
lit config, but clang does not do that, so we need to use the global
`system-darwin` here instead.

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

LoopFlatten does preserve loop analyses (DT, LI and SCEV), but
currently doesn't mark them as preserved in the NewPM (they are
marked as preserved in the LegacyPM). I think this doesn't really
have an effect in the end because the loop pass adaptor will just
assume they're preserved anyway, but let's be explicit about this
for the sake of clarity.

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

Updates the Bazel config for changes from
https://github.com/llvm/llvm-project/commit/3b01cf9286
by adding configuration for the new OpenMPOpsInterfaces tablegn target.

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

Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.

In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.

The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.

But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to li...

Some subprojects like compiler-rt define the `darwin` feature in their
lit config, but lld does not do that, so we need to use the global
system-darwin here instead. This test seems to have drifted from the
actual behavior so I also had to add `/usr/local/lib` here to make it
pass.

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