For every variable used under `#pragma omp task` directive
(`DeclRefExpr`) an ImplicitPrivateVariable is created in the AST, if
`private` or `shared` clauses are not present. If the variable has the
property of `non_odr_use_unevaluated` e.g. for statements which use
`sizeof( i )` `i` will have `non_odr_use_unevaluated` . In such cases
CodeGen was asserting by avoiding emitting of LLVM IR for such
variables. To prevent this assertion this checkin avoids adding the
ImplicitPrivateVariable for variables with `non_odr_use_unevaluated`.

---------

Authored-by: Sunil Kuravinakop <kuravina@pe28vega.us.cray.com>

Reland of https://github.com/llvm/llvm-project/pull/91334, which broke
the gcc7 buildbot and was reverted in
https://github.com/llvm/llvm-project/pull/92321.
Work around the failure by being explicit about returning an `Expected`.

cc @joker-eph

I accidentally left out the code to transfer sret attributes to entry
thunks, so values weren't being passed in the right registers, and the
sret pointer wasn't returned in the correct register.

Fixes #90229

Summary:
Currently this is only used for the zero-copy handling. However, this
can easily be moved into `libomptarget` so that we do not need to bother
setting the requires flags in the plugin. The advantage here is that we
no longer need to do this for every device redundently. Additionally,
these requires flags are specifically OpenMP related, so they should
live in `libomptarget`.

[DAG] SimplifyDemandedBits - use ComputeKnownBits instead of getValidShiftAmountConstant to check for constant shift amounts. (#92412)

This allows us to handle cases where the constant has already been type legalized behind a bitcast

Despite calling ComputeKnownBits I'm not seeing any notable change in compile time.

Address comments missed when landing
https://github.com/llvm/llvm-project/pull/85689.

This PR is an implementation for changes proposed in
https://discourse.llvm.org/t/rfc-distinguish-between-data-and-non-data-in-fir-alias-analysis/78759

Test updates were made when the query was on the wrong reference. So, it
is my hope that this will clear ambiguity on the nature of the queries
from here on.
There are also some TODOs that were addressed. 

It also partly implements what
https://github.com/llvm/llvm-project/pull/87723 is attempting to
accomplish. At least, on a point-to-point query between references, the
distinction is made. To apply it to TBAA, would be another PR.

Note that, the changes were minimal in the TBAA code to retain the
current results.

The -Wunsafe-buffer-usage warning should fire on any call to a function
annotated with [[clang::unsafe_buffer_usage]], however it omitted calls
to constructors, since the expression is a CXXConstructExpr which does
not subclass CallExpr. Thus the matcher on callExpr() does not find
these expressions.

Add a new WarningGadget that matches cxxConstructExpr that are calling a
CXXConstructDecl annotated by [[clang::unsafe_buffer_usage]] and fires
the warning. The new UnsafeBufferUsageCtorAttrGadget gadget explicitly
avoids matching against the std::span(ptr, size) constructor because
that is handled by SpanTwoParamConstructorGadget and we never want two
gadgets to match the same thing (and this is guarded by asserts).

The gadgets themselves do not report the warnings, instead each gadget's
Stmt is passed to the UnsafeBufferUsageHandler (implemented by
UnsafeBufferUsageReporter). The Reporter is previously hardcoded that a
CXXConstructExpr statement must be a match for std::span(ptr, size), but
that is no longer the case. We want the Reporter to generate different
warnings (in the -Wunsafe-buffer-usage-in-container subgroup) for the
span contructor. And we will want it to report more warnings for other
std-container-specific gadgets in the future. To handle this we allow
the gadget to control if the warning is general (it calls
handleUnsafeBufferUsage()) or is a std-container-specific warning (it
calls handleUnsafeOperationInContainer()).

Then the WarningGadget grows a virtual method to dispatch to the
appropriate path in the UnsafeBufferUsageHandler. By doing so, we no
longer need getBaseStmt in the Gadget interface. The only use of it for
FixableGadgets was to get the SourceLocation, so we make an explicit
virtual method for that on Gadget. Then the handleUnsafeOperation()
dispatcher can be a virtual method that is only in WarningGadget.

The SpanTwoParamConstructorGadget gadget dispatches to
handleUnsafeOperationInContainer() while the other WarningGadgets all
dispatch to the original handleUnsafeBufferUsage().

Tests are added for annotated constructors, conversion operattors, call
operators, fold expressions, and regular methods.

Issue #80482

Test for this paper were added in https://github.com/llvm/llvm-project/pull/91435

These tests failed in case of Windows host and Linux target, because
dap_server tried to run ELF file on Windows.

The `disconnect` response contains the `error` message with invalid
characters (a junk data). To reproduce this issue it is enough to run
the `TestDAP_commands` test on Windows host and Linux target. The test
will fail to run ELF file on Windows and dap_server will be disconnected
unexpectedly.

Note dap_server hangs if read_packet() cannot decode JSON with invalid
characters. read_packet() must return None in this case instead of an
exception. But dap_server does not require any fix after this patch.

Atomic update expression does not allow overloaded user-defined
operators. This PR adds a test case for the same; the semantic check is
already existent.

Fixes #88935

Toggling reduction by-ref broke when multiple reduction clauses were
used. Decisions made for the by-ref status for later clauses could then
invalidate decisions for earlier clauses. For example,

```
reduction(+:scalar,scalar2) reduction(+:array)
```

The first clause would choose by value reduction and generate by-value
reduction regions, but then after this the second clause would force
by-ref to support the array argument. But by the time the second clause
is processed, the first clause has already had the wrong kind of
reduction regions generated.

This is solved by toggling whether a variable should be reduced by
reference per variable. In the above example, this allows only `array`
to be reduced by ref.

[TableGen][SubtargetEmitter] Early exit from loop in FindWriteResources and FindReadAdvance (#92202)

This gives us a 30% speed improvement in our downstream.

The znver3/4 scheduler models have previously associated the LoopMicroOpBufferSize with the maximum size of their op caches, and when this led to quadratic complexity issues this were reduced to a value of 512 uops, based mainly on compilation time and not its effectiveness on runtime performance.

From a runtime performance POV, a large LoopMicroOpBufferSize leads to a higher number of loop unrolls, meaning the cpu has to rely on the frontend decode rate (4 ins/cy max) for much longer to fill the op cache before looping begins and we make use of the faster op cache rate (8/9 ops/cy).

This patch proposes we instead cap the size of the LoopMicroOpBufferSize based off the maximum rate from the op cache (znver3 = 8op/cy, znver4 = 9op/cy) and the branch misprediction penalty from the opcache (~12cy) as a estimate of the useful number of ops we can unroll a loop by before mispredictions are likely to cause stalls. This isn't a perfect metric, but does try to be closer to the spirit of how we use LoopMicroOpBufferSize in the compiler vs the size of a similar naming buffer in the cpu.

Fix `std/ranges/range.adaptors/range.lazy.split/general.pass.cpp` which
started failing on z/OS after this
[commit](https://github.com/llvm/llvm-project/commit/985c1a44f8d49e0af).

This test case is passing on other platforms such as AIX. This is
because the `__ALTIVEC__` macro is defined and `__mismatch` under
`_LIBCPP_VECTORIZE_ALGORITHMS` guard is compiled out. However, on z/OS
`_LIBCPP_VECTORIZE_ALGORITHMS` is defined. Analyzing the algorithm of
`__mismatch` shows that the culprit is the definition of
`__native_vector_size` which was defined wrongly as 1. This PR corrects
the definition of `__native_vector_size` and fixes the affected test.

According to specifications in
[ARM-software/acle/pull/309](https://github.com/ARM-software/acle/pull/309)
Add following intrinsics:

```
// svmax single,multi
svbfloat16x2_t svmax_single_bf16_x2(svbfloat16x2_t zdn, svbfloat16_t zm)
svbfloat16x4_t svmax_single_bf16_x4(svbfloat16x4_t zdn, svbfloat16_t zm)
svbfloat16x2_t svmax_bf16_x2(svbfloat16x2_t zdn, svbfloat16x2_t zm)
svbfloat16x4_t svmax_bf16_x4(svbfloat16x4_t zdn, svbfloat16x4_t zm)
```

```
// svmin single,multi
svbfloat16x2_t svmin_single_bf16_x2(svbfloat16x2_t zdn, svbfloat16_t zm)
svbfloat16x4_t svmin_single_bf16_x4(svbfloat16x4_t zdn, svbfloat16_t zm)
svbfloat16x2_t svmin_bf16_x2(svbfloat16x2_t zdn, svbfloat16x2_t zm)
svbfloat16x4_t svmin_bf16_x4(svbfloat16x4_t zdn, svbfloat16x4_t zm)
```

```
// svmaxnm single,multi
svbfloat16x2_t svmaxnm_single_bf16_x2(svbfloat16x2_t zdn, svbfloat16_t zm)
svbfloat16x4_t svmaxnm_single_bf16_x4(svbfloat16x4_t zdn, svbfloat16_t zm)
svbfloat16x2_t svmaxnm_bf16_x2(svbfloat16x2_t zdn, svbfloat16x2_t zm)
svbfloat16x4_t svmaxnm_bf16_x4(svbfloat16x4_t zdn, svbfloat16x4_t zm)
```

```
// svminnm single,multi
svbfloat16x2_t svminnm_single_bf16_x2(svbfloat16x2_t zdn, svbfloat16_t zm)
svbfloat16x4_t svminnm_single_bf16_x4(svbfloat16x4_t zdn, svbfloat16_t zm)
svbfloat16x2_t svminnm_bf16_x2(svbfloat16x2_t zdn, svbfloat16x2_t zm)
svbfloat16x4_t svminnm_bf16_x4(svbfloat16x4_t zdn, svbfloat16x4_t zm)
```
- Variations other than bfloat16 are already supported.

runCmd() is called from Base.getCPUInfo() but implemented only in
TestBase(Base). Usually it works if TestBase is used. But call
getCPUInfo() from a class based on Base will cause something like
```
File "E:\projects\llvm-nino\lldb\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1256, in getCPUInfo
  self.runCmd('platform get-file "/proc/cpuinfo" ' + cpuinfo_path)
AttributeError: 'TestGdbRemoteExpeditedRegisters' object has no attribute 'runCmd'
```
BTW, TestBase.setUp() called runCmd() before applying
LLDB_MAX_LAUNCH_COUNT and LLDB_TIME_WAIT_NEXT_LAUNCH.

This patch fixes the test TestGdbRemoteExpeditedRegisters in case of
Windows host and Linux target.

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.