This was missed in 8dbd745b

llvm-project/llvm/lib/Transforms/Utils/DemoteRegToStack.cpp:58:21:
error: unused variable 'BB' [-Werror,-Wunused-variable]
        BasicBlock *BB = SplitCriticalEdge(II, i);
                    ^
1 error generated.

Windows does not allow quotes in file names. So it is impossible to
build `libsvr4lib_b".so` on Windows.

The `Fortran::` namespace is redundant for all parts of the code in this
PR, except for names of functions in their definitions.

Currently the paths to compiler-rt and the Flang runtimes from the LLVM
build/install directory are preferred over any user-provided library
paths. This means a user can't override compiler-rt or the Flang
runtimes with custom versions.

This patch changes the link order to prefer library paths specified with
-L over the LLVM paths. This matches the behaviour of clang and flang on
Linux.

Update VectorizationPlan.rst to include a section about the current
status of VPlan and its use in LoopVectorize, based on "VPlan: Status
Update and Future Roadmap", LLVM Developers’ Meeting 2023,
https://www.youtube.com/watch?v=SzGP4PgMuLE

PR: https://github.com/llvm/llvm-project/pull/85689

llvm-project/llvm/lib/Transforms/Utils/DemoteRegToStack.cpp:54:23:
error: comparison of integers of different signs: 'int' and 'unsigned int' [-Werror,-Wsign-compare]
    for (int i = 0; i < CBI->getNumSuccessors(); i++) {
                    ~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

`llvm_test_dibuilder(/*NewDebugInfoMode=*/true)` isn't currently executed in 
`return llvm_test_dibuilder(false) && llvm_test_dibuilder(true);`
because `llvm_test_dibuilder` returns 0 for success.

Split the llvm-c-test flag `--test-dibuilder` into two, one for the old and
one for the new debug info format. Add another lit test for the new format.

Now that the test actually runs, it crashes using the new format with
`llvm/lib/IR/LLVMContextImpl.cpp:53:llvm::LLVMContextImpl::~LLVMContextImpl(): Assertion 'TrailingDbgRecords.empty() && "DbgRecords in blocks not cleaned"' failed. Aborted`.

Insert terminators into the blocks so that we don't leave the debug records
trailing, unattached to any instructions, which fixes that.

Fixes #90900

Limit the isConstOrConstSplat call to the vector elements we care about

Noticed while investigating regressions in #92096

Combiners that use C++ code in their "apply" pattern only use that. They
never mix it with MIR patterns as that has little added value.

This patch restricts C++ apply code so that if C++ is used, we cannot
use MIR patterns or builtins with it. Adding this restriction allows us
to merge calls to match and apply C++ code together, which in turns
makes it so we can just have MatchData variables on the stack.

So before, we would have
```
  GIM_CheckCxxInsnPredicate // match
  GIM_CheckCxxInsnPredicate // apply
  GIR_Done
```
Alongside a massive C++ struct holding the MatchData of all rules
possible (which was a big space/perf issue).

Now we just have
```
GIR_DoneWithCustomAction
```

And the function being ran just does
```
unsigned SomeMatchData;
if (match(SomeMatchData))
  apply(SomeMatchData)
```

This approach solves multiple issues in one:
- MatchData handling is greatly simplified and more efficient, "don't
pay for what you don't use"
  - We reduce the size of the match table
- Calling C++ code has a certain overhead (we need a switch), and this
overhead is only paid once now.

Handling of C++ code inside PatFrags is unchanged though, that still
emits a `GIM_CheckCxxInsnPredicate`. This is completely fine as they
can't use MatchDatas.

Two icmp/and combines forced computation of KnownBits on all operands
everytime. We can avoid computing KnownBits on the LHS by exploiting a
couple of properties:
- Constants are always on the RHS for those instructions. If we have no
KnownBits on the RHS, we can bail out early and avoid computing LHS
knownbits.
- For icmp uge/ult 0, we don't need to know the KBs of the LHS to infer
the result

This allows to save some KnownBits calls, which are very expensive,
without affecting codegen.

Fixes
https://github.com/llvm/llvm-project/pull/92084#issuecomment-2114083188.

Fixes https://github.com/llvm/llvm-project/issues/85192
Fixes https://github.com/llvm/llvm-project/issues/84492

This patch implements the "IsDeducible" constraint where the template
arguments of the alias template can be deduced from the returned type of
the synthesized deduction guide, per C++ [over.match.class.deduct]p4. In
the implementation, we perform the deduction directly, which is more
efficient than the way specified in the standard.

Also update relevant CTAD tests which were incorrectly compiled due to
the missing constraint.

By default (`shouldVisitImplicitCode()` returns `false`), RAV should not
traverse AST nodes that are not spelled in the source code. Deduction
guides for alias templates are always synthesized, so they should not be
traversed.

This is usually done by checking the implicit bit of the Decl. However,
this doesn't work deduction guides that are synthesized from explicit
user-defined deduction guides, as we must maintain the explicit bit to
ensure correct overload resolution.

Currently, `new struct S` fails to set any valid end source location
because the token corresponding to `S` is consumed in
`ParseClassSpecifier` and is not accessible in the
`ParseDeclarationSpecifiers` that normally sets the end source location.

Fixes #35300

This reverts commit f0b36547.

This commit triggers UB by reading an uninitialized variable.

`UP.PartialThreshold` is used uninitialized in `getUnrollingPreferences()` when
it is called from `LoopVectorizationPlanner::executePlan()`. In this case the
`UP` variable is created on the stack and its fields are not initialized.

```
==8802==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x557c0b081b99 in llvm::BasicTTIImplBase<llvm::X86TTIImpl>::getUnrollingPreferences(llvm::Loop*, llvm::ScalarEvolution&, llvm::TargetTransformInfo::UnrollingPreferences&, llvm::OptimizationRemarkEmitter*) llvm-project/llvm/include/llvm/CodeGen/BasicTTIImpl.h
    #1 0x557c0b07a40c in llvm::TargetTransformInfo::Model<llvm::X86TTIImpl>::getUnrollingPreferences(llvm::Loop*, llvm::ScalarEvolution&, llvm::TargetTransformInfo::UnrollingPreferences&, llvm::OptimizationRemarkEmitter*) llvm-project/llvm/include/llvm/Analysis/TargetTransformInfo.h:2277:17
    #2 0x557c0f5d69ee in llvm::TargetTransformInfo::getUnrollingPreferences(llvm::Loop*, llvm::ScalarEvolution&, llvm::TargetTransformInfo::UnrollingPreferences&, llvm::OptimizationRemarkEmitter*) const llvm-project/llvm/lib/Analysis/TargetTransformInfo.cpp:387:19
    #3 0x557c0e6b96a0 in llvm::LoopVectorizationPlanner::executePlan(llvm::ElementCount, unsigned int, llvm::VPlan&, llvm::InnerLoopVectorizer&, llvm::DominatorTree*, bool, llvm::DenseMap<llvm::SCEV const*, llvm::Value*, llvm::DenseMapInfo<llvm::SCEV const*, void>, llvm::detail::DenseMapPair<llvm::SCEV const*, llvm::Value*>> const*) llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7624:7
    #4 0x557c0e6e4b63 in llvm::LoopVectorizePass::processLoop(llvm::Loop*) llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:10253:13
    #5 0x557c0e6f2429 in llvm::LoopVectorizePass::runImpl(llvm::Function&, llvm::ScalarEvolution&, llvm::LoopInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::BlockFrequencyInfo*, llvm::TargetLibraryInfo*, llvm::DemandedBits&, llvm::AssumptionCache&, llvm::LoopAccessInfoManager&, llvm::OptimizationRemarkEmitter&, llvm::ProfileSummaryInfo*) llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:10344:30
    #6 0x557c0e6f2f97 in llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:10383:9

[...]

  Uninitialized value was created by an allocation of 'UP' in the stack frame
    #0 0x557c0e6b961e in llvm::LoopVectorizationPlanner::executePlan(llvm::ElementCount, unsigned int, llvm::VPlan&, llvm::InnerLoopVectorizer&, llvm::DominatorTree*, bool, llvm::DenseMap<llvm::SCEV const*, llvm::Value*, llvm::DenseMapInfo<llvm::SCEV const*, void>, llvm::detail::DenseMapPair<llvm::SCEV const*, llvm::Value*>> const*) llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:7623:3
```

This commit refactors GenericTaintChecker and performs various
improvements in the list of taint propagation functions:

1. The matching mode (usually `CDM::CLibrary` or
`CDM::CLibraryMaybeHardened`) was specified to avoid matching e.g. C++
methods or functions from a user-defined namespace that happen to share
the name of a well-known library function.
2. With these matching modes, a `CallDescription` can automatically
match builtin variants of the functions, so entries that explicitly
specified a builtin function were removed. This eliminated
inconsistencies where the "normal" and the builtin variant of the same
function was handled differently (e.g. `__builtin_strlcat` was covered,
while plain `strlcat` wasn't; while `__builtin_memcpy` and `memcpy` were
both on the list with different propagation rules).
3. The modeling of the functions `strlcat` and `strncat` was updated to
propagate taint from the first argument (index 0), because a tainted
string should remain tainted even if we append something else to it.
Note that this was already applied to `strcat` and `wcsncat` by commit
6ceb1c0e.
4. Some functions were updated to propagate taint from a size/length
argument to the result: e.g. `memcmp(p, q, get_tainted_int())` will now
return a tainted value (because the attacker can manipulate it). This
principle was already present in some propagation rules (e.g.
`__builtin_memcpy` was handled this way), and even after this commit
there are still some functions where it isn't applied. (I only aimed for
consistency within the same function family.)
5. Functions that have hardened `__FOO_chk()` variants are matched in
`CDM:CLibraryMaybeHardened` to ensure consistent handling of the
"normal" and the hardened variant. I added special handling for the
hardened variants of "sprintf" and "snprintf" because there the extra
parameters are inserted into the middle of the parameter list.
6. Modeling of `sscanf_s` was added, to complete the group of `fscanf`,
`fscanf_s` and `sscanf`.
7. The `Source()` specifications for `gets`, `gets_s` and `wgetch` were
ill-formed: they were specifying variadic arguments starting at argument
index `ReturnValueIndex`. (That is, in addition to the return value they
were propagating taint to all arguments.)
8. Functions that were related to each other were grouped together. (I
know that this makes the diff harder to read, but I felt that the full
list is unreadable without some reorganization.)
9. I spotted and removed some redundant curly braces. Perhaps would be
good to switch to a cleaner layout with less nested braces...
10. I updated some obsolete comments and added two TODOs for issues that
should be fixed in followup commits.

This allows `TransferOptimization` to eliminate and forward stores that
are to trivial aliases (rather than just to identical memref values).

A trivial aliases is (currently) defined as:

  1. A `memref.cast`
  2. A `memref.subview` with a zero offset and unit strides
  3. A chain of 1 and 2

https://lab.llvm.org/buildbot/#/builders/272/builds/16745

The previous logic did not consider whether the architectural features
meet the requirements of the ABI, resulting in the generation of
incorrect object files in some cases. For example:

```
llc -mtriple=loongarch64 -filetype=obj test/CodeGen/LoongArch/ir-instruction/fadd.ll -o t.o
llvm-readelf -h t.o
```
The object file indicates the ABI as lp64d, however, the generated code
is lp64s.

The new logic introduces the `feature-implied` ABI. When both target-abi
and triple-implied ABI are invalid, the feature-implied ABI is used.

Reviewed By: SixWeining, xen0n

Pull Request: https://github.com/llvm/llvm-project/pull/92223

This is a pre-commit for modifying `computeTargetABI` logic.

This patch will provide warning prompts when using those ABIs that have
not yet been standardized.

Reviewed By: xen0n, SixWeining

Pull Request: https://github.com/llvm/llvm-project/pull/92222

This only handles one case (that's fairly common in practice*), storing
a masked constant splat, then reloading again with the same mask and a
padding value that matches the splat.

* For SVE/SME (without peeling) this occurs when you have a
`linalg.fill` preceding a `linalg.matmul`.

This moves the architecture version, profile and extension information
into tablegen, and generates the TargetParser ArchInfo objects from
this data.

There are two lists of "dependencies" defined for each architecture: the
SubtargetFeature::Implies which controls which features are
automatically enabled in the backend when the corresponding architecture
SubtargetFeature is enabled; and the list of Extensions which are
enabled by default for this architecture. As far as I can tell, the idea
here is that the SubtargetFeature models the mandatory dependencies (although
they can still be disabled if desired) while the default extensions models
the typical use case for that architecture.

.md files should be included into other .md files so they don't show up in the
top-level menu.

The ODS-generated code has the following:

```
::mlir::TypedValue<::mlir::transform::OperationType> getAlloca() {
  return ::llvm::cast<::mlir::TypedValue<::mlir::transform::OperationType>>(
      *getODSOperands(0).begin());
}
```

that may require the compiler seing the definition of `OperationType` so
include the corresponding header.

Co-authored-by: Nikita Popov <github@npopov.com>

This is same as #90905 with an added fix. The issue was that we
generated variable info even when user asked for line-tables-only. This
caused llvm dwarf generation code to fail an assertion as it expected an
empty variable list.

Fixed by not generating debug info for variables when user wants only
line table. I also updated a test check for this case.

Extends pack/unpack perm attribute checker to account for cases when the
optional outer_dims_perm attribute might be missing in one operation and
the other one has explicit identity permutation. This enables
canonicalizer to fold more unpack(pack(x)) variants.

The feature test macro was renamed when
[P2641R4](https://wg21.link/P2641R4) was adopted into the standard:
https://github.com/cplusplus/draft/commit/0facada4cadd97e1ba15bfaea76a804f1dc5c309
https://wg21.link/version.syn#lib:__cpp_lib_is_constant_evaluated

This patch deprecates StringRef::equals.  Note that I've migrated all
known users to operator==(StringRef, StringRef).

Unsupported ops on tile types can become dead after
`-convert-arm-sme-to-llvm` resulting in incorrect results. Verify such
operations don't exist post-conversion and fail if they do.

Based on discussion from
https://discourse.llvm.org/t/on-improving-arm-sme-lowering-resilience-in-mlir/78543

Addresses old TODO about the exp10 intrinsic not existing.

Support `R_AARCH64_AUTH_RELATIVE` relocation compression as described in
https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst#relocation-compression

If there is only one non-terminator operation in the update region then
the update operation can be found and we can try to generate an
atomicrmw instruction. Otherwise use the cmpxchg loop.

Fixes #91929