This patch reworks generation for the `CFGScopeBegin`, `CFGScopeEnd`,
and `CFGLiftimeEnd`, in a way that they are now compatible with each
other and `CFGAutomaticObjDtor`. All of the above elements are now
generated by a single code path, that conditionally inserts elements if
they are requested.

In addition, the handling of `goto` statements is improved.
The `goto` statement may leave multiple scopes (and trigger destruction
and lifetime end for the affected variables) and enter multiple scopes,
for example:
```lang=C++
{
  int s1;
  {
    int s2;
    goto label; // leaves s1, s2, and enters t1 t1
  }
}
{
  int t1;
  {
    int t2;
label:
  }
}
```
This is performed by first determining the shared parent scope of the
source and destination. And then emitting elements for exiting each
scope between the source and the parent, and entering each scope
between the parent and destination. All such elements are appended
to the source block, as one label may be reached from multiple scopes.

Finally, the approach for handling backward jumps is changed. When
connecting a source block to a destination block that requires the
insertion of additional elements, we put this element into a new block,
which is then linked between the source and the destination block.
For example:
```lang=C++
{
  int t;
label:
  // Destination block referred to as 'DB'
}
{
  // Source block referred to as 'SB'
  Obj s;
  goto label;
}
```

The jump between `SB` with terminator `T: goto` and `DB` should be
coupled with the following CFG elements:
```
CFGAutomaticObjDtor(s)
CFGLifetimeEnd(s)
CFGScopeEnd(s)
CFGScopeBegin(t)
```

To handle such situations, we create a new link (`LB`) that is linked as
the predecessor of `DB`, to which we transfer the terminator (`goto`
statement) of `SB`. Then `LB` is handled in the same manner as the
source block in the case of forward jumps.
This produces CFG that looks like this:
```
SB -> LB (T: goto) -> DB
```

Finally, the resulting block is linked as the successor of `SB`. Such an
approach uses existing handling of the `noreturn` destructors.
As a reminder, for each destructor of an automatic object that is
marked as `noreturn`, a new `noreturn` block (marked `NBn`) is
created, at the destructor is inserted at the end of it.
To illustrate, given two `noreturn` destructors, we will have:
```
SB -> NB1 (noreturn)
NB2 (noreturn)
LB (T:goto) -> DB
```

Reviewed By: ymandel, steakhal

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

ArgumentParser expands @ (fromfile_prefix_chars) by default, so the
expansion code path is unused.

Intercept `_strdup` on windows, instead of the nonexistent `strdup`.

The reasons are:
1, `AVRMCCodeEmitter::emitInstruction` has only one use which is `AVRMCCodeEmitter::encodeInstruction`, and the parameter `STI` is not used in this function. I think it might be copied from other target.
2, We do have `AVRAsmPrinter::emitInstruction`, and it would invoke `AVRMCCodeEmitter::encodeInstruction` in its calling chain, so if we call `AVRMCCodeEmitter::emitInstruction` in `AVRMCCodeEmitter::encodeInstruction`, it would be confusing.

Reviewed By: benshi001

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

Enable fuzzer on loongarch64.

Reviewed By: SixWeining, xen0n, MaskRay

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

This reverts commit d618f1c3.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it landed. According to our developer policy
this warrants immediate revert of the commit.

https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

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

If the paddingAttr is an ArrayAttr with two values we know that
the element type is a `ComplexType` and we should pad the value
accordingly.

Reviewed By: mravishankar

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

CMP(A,C)||CMP(B,C) => CMP(MIN/MAX(A,B), C)
CMP(A,C)&&CMP(B,C) => CMP(MIN/MAX(A,B), C)

This first patch handles integer types.

Reviewed By: craig.topper

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

Reviewed By: arsenm

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

Noticed by inspection of
b7836d85. This was checking if the
first instruction was a copy, not the current MI. It should fully
respect the isCopyInstr result. Hopefully this fixes a reported
regression which we can extract a test from.

This needs to consider the dynamic denormal mode. It should be
possible to implement a runtime DAZ check with a canonicalize.

While Clang targets have supported __builtin_thread_pointer for a very
long time (e.g., 2007 for AArch32, 2015 for AArch64), for some GCC
ports, the support is very new (11.0 for x86[1], while we need to
support GCC 7), and many ports haven't implemented
__builtin_thread_pointer yet (m68k, powerpc, etc).

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96955

The test fails on some builders but not on others; there's likely some
kind of environment dependence that should be investigated.

See https://reviews.llvm.org/D155317

Reviewers: enh, pirama, srhines, asb

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

This reverts commit 702a4d89.

Can break calling convention restrictions.

BEXT and BEXTI may behave differently from other Zbs instructions.
Split the write classes so these differences may be modeled by
scheduler models.

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

Add the scheduling model for Neoverse V1.

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

The empty.sh.cpp test never tested what it was intended to test, because
it did contain an unexpected RUN: command. This was discovered in
https://reviews.llvm.org/D154987 while trying to land an unrelated change.
Since there is no reliable way to test what I was trying to test from
the libc++ test suite, just remove the test.

Reading this code, I noticed that we call findMatInsertPt a lot, for the
same inputs. Calculate it once and save the result.

Reviewed By: MaskRay

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

This provides better error messages when the program terminates due to
an exception being thrown in -fno-exceptions mode. Those seem to have
been missed in https://reviews.llvm.org/D141222.

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

This option had originally been added in D83069 to allow disabling the
check that something is going to get run at all when a specific test name
is used on the command-line. Since we now use getTestsForPath() (from D151664)
to get the tests to run for a specific path, we don't need a specific check
for this anymore -- Lit will produce the same complaint it would produce if
you provided a directory with no tests.

If one needs to run a specific test on the command-line and the Lit
configuration would normally not include that test, the configuration
should be set up as a "standalone" configuration or it should be fixed
to allow for that test to be found (i.e. probably fix the allowed test
suffixes).

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

This reverts commit 0d21b7cb.

Causes broken IR, test case provided at
https://reviews.llvm.org/rG0d21b7cbdeb2f2eb5ef123a15099da0b651b24c0

We pack this info in a tuple just to spread it back out for a function
call. Spreads in C++ are awkward.  If I want to add an additional
element to the tuple, I need to add more calls to std::get<> later. Just
use a struct.

Reviewed By: void

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

Special casing the nonfinite exponent value everywhere is kind of
annoying.

Handle constant folding and idempotent folding. Not sure
this is an appropriate use of undef for the inf/nan case. The
C version says the second result is "unspecified". The AMDGPU
instruction returns 0.

Fixes regression reported after
0f4eb557

Identified another miscompile while working on fixing interleaving's
current miscompile in D154309. This is different from testcases landed in D154309,
since it showcases an incorrect sinking of store (the former testcases
in that review and follow-up ones) showed incorrect hoisting of loads
across stores.

Transformed if checks to asserts and simplified some more code to
improve compile time.

Linalg operations can include `complex` types in the src/target types.
This should include conversion between `arith` and `complex` types when
constructing `linalg` operations.

Reviewed By: kuhar

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

Instead of warning possibly up to 3 times about the same problem,
warn only about the actual missing directories.

This reverts commit 9b3323d3.

The warning will stay DefaultIgnore upstream, because a variety of
tests aren't expecting it and updating the tests isn't worth the
effort.

Before D150478, there were situations when Clang avoided parsing a module map because it was likely to re-define an already defined module (either by a PCM or by previously-found module map). Since Clang no longer performs that check and does parse the extra module map (due to the FW/FW_Private issue described in D150478), this patch re-implements the same semantics by skipping the duplicate definition of the framework module while parsing the module map.

Depends on D150478.

Reviewed By: benlangmuir

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

When Clang loads a PCM that depends on another PCM describing framework module "FW", `ModuleMap` registers "FW" as known, without seeing the module map that defines it (or the adjacent "FW_Private" module map). Later, when looking at a header from "FW_Private", `ModuleMap` returns early due to having knowledge about "FW" and never associates that header with "FW_Private", leading to it being treated as textual. This behavior is caused by D150292, where the scanner stops calling `HeaderSearch::lookupModule()` eagerly for every loaded PCM.

This patch skips an early check when trying to figure out the framework module for a header, which ensures the "FW" and (most importantly) "FW_Private" module maps can be parsed even after loading "FW" from a PCM. Note that the `HeaderSearch::loadModuleMapFile()` function we not call unconditionally has caching behavior of its own, meaning it will avoid parsing module map file repeatedly.

Depends on D150320.

Reviewed By: benlangmuir

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