[CSSPGO] Honor preinliner decision for ThinLTO importing

When pre-inliner decision is used for CSSPGO, we should take that into account for ThinLTO importing as well, so post-link sample loader inliner can favor that decision. This is handled by a small tweak in this patch. It also includes a change to transfer preinliner decision when merging context.

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

Revert "[analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it"

This reverts commit 7d0e62bfb773c68d2bc8831fddcc8536f4613190.

[flang] Fix non-deterministic line output function

The evaluation order for the `|` operator is undefined
(in contrast to the short-circuiting `||` operator). The arguments are
stored in variables to force a specific evaluation order.

A test in D107575 relies on this change.

Reviewed By: kiranchandramohan, klausler

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

[AArch64][SVE] Workaround incorrect types when lowering fixed length gather/scatter

When lowering a fixed length gather/scatter the index type is assumed to
be the same as the memory type, this is incorrect in cases where the
extension of the index has been folded into the addressing mode.

For now add a temporary workaround to fix the codegen faults caused by
this by preventing the removal of this extension. At a later date the
lowering for SVE gather/scatters will be redesigned to improve the way
addressing modes are handled.

As a short term side effect of this change, the addressing modes
generated for fixed length gather/scatters will not be optimal.

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

[InstrProfiling] Add one missing XCOFF line to profiling.ll

[analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it

D105553 added NoStateChangeFuncVisitor, an abstract class to aid in creating
notes such as "Returning without writing to 'x'", or "Returning without changing
the ownership status of allocated memory". Its clients need to define, among
other things, what a change of state is.

For code like this:

f() {
  g();
}

foo() {
  f();
  h();
}

We'd have a path in the ExplodedGraph that looks like this:

             -- <g> -->
            /          \
         ---     <f>    -------->        --- <h> --->
        /                        \      /            \
--------        <foo>             ------    <foo>     -->

When we're interested in whether f neglected to change some property,
NoStateChangeFuncVisitor asks these questions:

                       ÷×~
                -- <g> -->
           ß   /          \$    @&#*
            ---     <f>    -------->        --- <h> --->
           /                        \      /            \
   --------        <foo>             ------    <foo>     -->

Has anything changed in between # and *?
Has anything changed in between & and *?
Has anything changed in between @ and *?
...
Has anything changed in between $ and *?
Has anything changed in between × and ~?
Has anything changed in between ÷ and ~?
...
Has anything changed in between ß and *?
...
This is a rather thorough line of questioning, which is why in D105819, I was
only interested in whether state *right before* and *right after* a function
call changed, and early returned to the CallEnter location:

if (!CurrN->getLocationAs<CallEnter>())
  return;
Except that I made a typo, and forgot to negate the condition. So, in this
patch, I'm fixing that, and under the same hood allow all clients to decide to
do this whole-function check instead of the thorough one.

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

[RISCV] Teach instruction selection to elide sext.w in some cases.

If a sext_inreg is up for isel, and all its users are W instructions,
we can skip emitting the sext_inreg. This helpful if the producing
instruction can't become a W instruction.

Reviewed By: asb

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

[RISCV] Enable shrink wrap by default

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

[RISCV] Split PseudoVSETVLI into 2 instructions to allow different register classes for rs1.

X0 has special meaning for vsetvli, we need to make sure we never
create it a vsetvli that uses it by accident. This could happen
if the register coalescer coalesces a copy from X0 into this
instruction.

This patch splits the instruction so that we can have GPRNoX0
register class to use for the cases where we don't want the source
to be X0. The verifier won't let us explicitly use X0 on a GPRNoX0
operand so we need a separate pseudo for those cases.

I don't currently have a failing example for this. There was a
failure in D107957, but the coalescable copy from that example
should have been optimized away much earlier so I've fixed that.

This is not a complete fix. We still need to prevent the same
possible issue on the AVL operand of all of the vector instruction
pseudos. I don't want to make two versions of all of those so we
need to find a different solution for those. I have an idea I'm
going to try.

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

[clang-cl] Emit nicer warning on unknown /arch: arguments

Now prints the list of known archs. This requires plumbing a Driver
arg through a few functions.

Also add two more convenience insert() overlods to StringMap.

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

[MLIR][OpenMP] Add support for declaring critical construct names

Add an operation omp.critical.declare to declare names/symbols of
critical sections. Named omp.critical operations should use symbols
declared by omp.critical.declare. Having a declare operation ensures
that the names of critical sections are global and unique. In the
lowering flow to LLVM IR, the OpenMP IRBuilder creates unique names
for critical sections.

Reviewed By: ftynse, jeanPerier

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

[AMDGPU] Add merging into S_BUFFER_LOAD_DWORDX8_IMM

Extend SILoadStoreOptimizer to merge into DWORDX8 variant of S_BUFFER_LOAD.

Merging into DWORDX2 and DWORDX4 variants is handled already.

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

[mlir] Add Cpp emitter

This upstreams the Cpp emitter, initially presented with [1], from [2]
to MLIR core. Together with the previously upstreamed EmitC dialect [3],
the target allows to translate MLIR to C/C++.

[1] https://reviews.llvm.org/D76571
[2] https://github.com/iml130/mlir-emitc
[3] https://reviews.llvm.org/D103969

Co-authored-by: Jacques Pienaar <jpienaar@google.com>
Co-authored-by: Simon Camphausen <simon.camphausen@iml.fraunhofer.de>
Co-authored-by: Oliver Scherf <oliver.scherf@iml.fraunhofer.de>
Reviewed By: jpienaar

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

[mlir] support translating OpenMP loops with reductions

Use the recently introduced OpenMPIRBuilder facility to transate OpenMP
workshare loops with reductions to LLVM IR calling OpenMP runtime. Most of the
heavy lifting is done at the OpenMPIRBuilder. When other OpenMP dialect
constructs grow support for reductions, the translation can be updated to
operate on, e.g., an operation interface for all reduction containers instead
of workshare loops specifically. Designing such a generic translation for the
single operation that currently supports reductions is premature since we don't
know how the reduction modeling itself will be generalized.

Reviewed By: kiranchandramohan

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

Revert "[lldb server] Tidy up LLDB server return codes and associated tests"

This reverts commit e387c8c413e2127bc93950fb6d786290237b4a9f. The
TestErrorMessages.test is failing on the Linux bots.

[ARM] Add a tail-predication loop predicate register

The semantics of tail predication loops means that the value of LR as an
instruction is executed determines the predicate. In other words:

mov r3, #3
DLSTP lr, r3        // Start tail predication, lr==3
VADD.s32 q0, q1, q2 // Lanes 0,1 and 2 are updated in q0.
mov lr, #1
VADD.s32 q0, q1, q2 // Only first lane is updated.

This means that the value of lr cannot be spilled and re-used in tail
predication regions without potentially altering the behaviour of the
program. More lanes than required could be stored, for example, and in
the case of a gather those lanes might not have been setup, leading to
alignment exceptions.

This patch adds a new lr predicate operand to MVE instructions in order
to keep a reference to the lr that they use as a tail predicate. It will
usually hold the zeroreg meaning not predicated, being set to the LR phi
value in the MVETPAndVPTOptimisationsPass. This will prevent it from
being spilled anywhere that it needs to be used.

A lot of tests needed updating.

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

[clang] NFC: Extract DiagnosticOptions parsing

The way we parse `DiagnosticOptions` is a bit involved.

`DiagnosticOptions` are parsed as part of the cc1-parsing function `CompilerInvocation::CreateFromArgs` which takes `DiagnosticsEngine` as an argument to be able to report errors in command-line arguments. But to create `DiagnosticsEngine`, `DiagnosticOptions` are needed. This is solved by exposing the `ParseDiagnosticArgs` to clients and making its `DiagnosticsEngine` argument optional, essentially breaking the dependency cycle.

The `ParseDiagnosticArgs` function takes `llvm::opt::ArgList &`, which each client needs to create from the command-line (typically represented as `std::vector<const char *>`). Creating this data structure in this context is somewhat particular. This code pattern is copy-pasted in some places across the upstream code base and also in downstream repos. To make things a bit more uniform, this patch extracts the code into a new reusable function: `CreateAndPopulateDiagOpts`.

Reviewed By: dexonsmith

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

Revert @llvm.isnan intrinsic patchset.

Please refer to
https://lists.llvm.org/pipermail/llvm-dev/2021-September/152440.html
(and that whole thread.)

TLDR: the original patch had no prior RFC, yet it had some changes that
really need a proper RFC discussion. It won't be productive to discuss
such an RFC, once it's actually posted, while said patch is already
committed, because that introduces bias towards already-committed stuff,
and the tree is potentially in broken state meanwhile.

While the end result of discussion may lead back to the current design,
it may also not lead to the current design.

Therefore i take it upon myself
to revert the tree back to last known good state.

This reverts commit 4c4093e6e39fe6601f9c95a95a6bc242ef648cd5.
This reverts commit 0a2b1ba33ae6dcaedb81417f7c4cc714f72a5968.
This reverts commit d9873711cb03ac7aedcaadcba42f82c66e962e6e.
This reverts commit 791006fb8c6fff4f33c33cb513a96b1d3f94c767.
This reverts commit c22b64ef66f7518abb6f022fcdfd86d16c764caf.
This reverts commit 72ebcd3198327da12804305bda13d9b7088772a8.
This reverts commit 5fa6039a5fc1b6392a3c9a3326a76604e0cb1001.
This reverts commit 9efda541bfbd145de90f7db38d935db6246dc45a.
This reverts commit 94d3ff09cfa8d7aecf480e54da9a5334e262e76b.

[clang] NFC: Remove duplicate DependentSizedMatrixType methods

Inherited from MatrixType.

Reviewed By: fhahn

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

[lldb] [client] Implement follow-fork-mode

Implement a new target.process.follow-fork-mode setting to control
LLDB's behavior on fork.  If set to 'parent', the forked child is
detached and parent continues being traced.  If set to 'child',
the parent is detached and child becomes traced instead.

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

[libomptarget][amdgpu] Drop env variables

Use the same debug print as the rest of libomptarget plugins with
the same environment control. Also drop the max queue size debugging hook as
I don't believe it is still in use, can bring it back near the rest of the env
handling in rtl.cpp if someone objects.

That makes most of rt.h and all of utils.cpp unused. Clean that up and simplify
control flow in a couple of places.

Behaviour change is that debug prints that used to use the old environment
variable now use the new one and print in slightly different format, and the
removal of the max queue size variable.

Reviewed By: pdhaliwal

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

[X86] Fold PMADD(x,0) or PMADD(0,x) -> 0

Pulled out of D108522 - handle zero-operand cases for PMADDWD/VPMADDUBSW ops

[X86][SSE] Add combine-pmadd.ll for PMADDWD/VPMADDUBSW combines

Pre-commit for D108522 to show failure to fold multiply by zero operands

[libunwind] Compile with -Wunused-but-set-variable

-Wunused-but-set-variable triggers a warning even the block of code is effectively dead.

Reviewed By: MaskRay

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

Revert "[OpenMP][OpenMPIRBuilder] Implement loop unrolling."

Breaks build with -DBUILD_SHARED_LIBS=ON
```
CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
  "LLVMFrontendOpenMP" of type SHARED_LIBRARY
    depends on "LLVMPasses" (weak)
  "LLVMipo" of type SHARED_LIBRARY
    depends on "LLVMFrontendOpenMP" (weak)
  "LLVMCoroutines" of type SHARED_LIBRARY
    depends on "LLVMipo" (weak)
  "LLVMPasses" of type SHARED_LIBRARY
    depends on "LLVMCoroutines" (weak)
    depends on "LLVMipo" (weak)
At least one of these targets is not a STATIC_LIBRARY.  Cyclic dependencies are allowed only among static libraries.
CMake Generate step failed.  Build files cannot be regenerated correctly.
```

This reverts commit 707ce34b06190e275572c3c46843036db1bab6d1.

[Unwind] Harmonise exception class for EHABI spec.

EHABI defines the exception class as char[8] instead of uint64_t [1].
For ABI compatibility the ABI the definition needs to be updated.

[1] https://github.com/ARM-software/abi-aa/blob/main/ehabi32/ehabi32.rst#82language-independent-unwinding-types-and-functions

Reviewed By: manojgupta, MaskRay, #libunwind

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

[RISCV][test] Add more tests for (mul (add x, c1), c2)

Reviewed By: asb

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

[RISCV][test] Add tests for optimization with SH*ADD in the zba extension

Reviewed By: asb

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

[LegalizeTypes][VP] Add splitting support for binary VP ops

This patch extends D107904's introduction of vector-predicated (VP)
operation legalization to include vector splitting.

When the result of a binary VP operation needs splitting, all of its
operands are split in kind. The two operands and the mask are split as
usual, and the vector-length parameter EVL is "split" such that the low
and high halves each execute the correct number of elements.

Tests have been added to the RISC-V target to show splitting several
scenarios for fixed- and scalable-vector types. Without support for
`umax` (e.g. in the `B` extension) the generated code starts to branch.
Ideally a cost model would prevent their insertion in the first place.

Through these tests many opportunities for better codegen can be seen:
combining known-undef VP operations and for constant-folding operations
on `ISD::VSCALE`, to name but a few.

Reviewed By: RKSimon

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

[VP] Declaration and docs for vp.select intrinsic

llvm.vp.select extends the regular select instruction with an explicit
vector length (%evl).

All lanes with indexes at and above %evl are
undefined. Lanes below %evl are taken from the first input where the
mask is true and from the second input otherwise.

Reviewed By: rogfer01

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

[lldb server] Tidy up LLDB server return codes and associated tests

This diff modifies the LLDB server return codes to more accurately reflect usage
error paths. Specifically we always propagate the return codes from the main
entrypoints into GDB remote LLDB server, and platform LLDB server. This way, the
top-level caller of LLDB server will be able to correctly check whether the
executable exited with or without an error.

We additionally modify and extend the associated shell unit tests to expect
nonzero return codes on error conditions.

Test Plan:
LLDB tests pass:

```
ninja check-lldb
```

Reviewed By: teemperor

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

[mlir][linalg] Expose function to create op on buffers during bufferization.

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

[SVE] Fix the FP arithmetic instruction costs for SVE

Several FP instructions (fadd, fsub, etc.) were incorrectly assigned
a higher cost for SVE because they have custom lowering, however we
know they are legal. This patch explicitly assigns a cost of 2 to
these opcodes.

Tests added here:

  Analysis/CostModel/AArch64/arith-fp-sve.ll

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

[MC] Set SHF_INFO_LINK on SHT_REL/SHT_RELA sections

sh_info links to a section, therefore SHF_INFO_LINK should be set as GNU as
does. The issue has been benign because linkers kindly combines relocation
sections w/ and w/o the flag.

[SelectionDAG][VP] Fix VP memory ops' EVL/Mask indices

This patch corrects the auto-generated EVL and Mask index positions of
the `VP_LOAD`/`VP_STORE`/`VP_GATHER`/`VP_SCATTER` nodes.

Reviewed By: simoll

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

[OpenMP][OpenMPIRBuilder] Implement loop unrolling.

Add methods for loop unrolling to the OpenMPIRBuilder class and use them in Clang if `-fopenmp-enable-irbuilder` is enabled. The unrolling methods are:

 * `unrollLoopFull`
 * `unrollLoopPartial`
 * `unrollLoopHeuristic`

`unrollLoopPartial` and `unrollLoopHeuristic` can use compiler heuristics to automatically determine the unroll factor. If possible, that is if no CanonicalLoopInfo is required to pass to another method, metadata for LLVM's LoopUnrollPass is added. Otherwise the unroll factor is determined using the same heurstics as user by LoopUnrollPass. Not requiring a CanonicalLoopInfo, especially with `unrollLoopHeuristic` allows greater flexibility.

With full unrolling and partial unrolling with known unroll factor, instead of duplicating instructions by the OpenMPIRBuilder, the full unroll is still delegated to the LoopUnrollPass. In case of partial unrolling the loop is first tiled using the existing `tileLoops` methods, then the inner loop fully unrolled using the same mechanism.

Reviewed By: jdoerfert, kiranchandramohan

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

[LoopDistribute] Add tests inspired by PR50296, PR50288.

[CSSPGO] Use preinliner decision by default when available

For CSSPGO, turn on `sample-profile-use-preinliner` by default. This simplifies the use of llvm-profgen preinliner as it's now simply driven by ContextShouldBeInlined flag for each context profile without needing extra compiler switch.

Note that llvm-profgen's preinliner is still off by default, under switch `csspgo-preinliner`.

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

[docs] Mention that the legacy PM is deprecated and will be removed after 14

Per https://lists.llvm.org/pipermail/llvm-dev/2021-August/152305.html.

Reviewed By: MaskRay, fhahn

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

[NPM] Added opt option -print-pipeline-passes.

Added opt option -print-pipeline-passes to print a -passes compatible
string describing the built pass pipeline.

As an example:
$ opt -enable-new-pm=1 -adce -licm -simplifycfg -o /dev/null /dev/null -print-pipeline-passes
verify,function(adce),function(loop-mssa(licm)),function(simplifycfg<bonus-inst-threshold=1;no-forward-switch-cond;no-switch-to-lookup;keep-loops;no-hoist-common-insts;no-sink-common-insts>),verify,BitcodeWriterPass

At the moment this is best-effort only and there are some known
limitations:
- Not all passes accepting parameters will print their parameters
  (currently only implemented for simplifycfg).
- Some ClassName to pass-name mappings are not unique.
- Some ClassName to pass-name mappings are missing (e.g.
  BitcodeWriterPass).

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

Revert "[NPM] Added opt option -print-pipeline-passes."

This reverts commit c71869ed4c24b3d4d13e2f83ee2c0104013ca129.

[NPM] Added opt option -print-pipeline-passes.

Added opt option -print-pipeline-passes to print a -passes compatible
string describing the built pass pipeline.

As an example:
$ opt -enable-new-pm=1 -adce -licm -simplifycfg -o /dev/null /dev/null -print-pipeline-passes
verify,function(adce),function(loop-mssa(licm)),function(simplifycfg<bonus-inst-threshold=1;no-forward-switch-cond;no-switch-to-lookup;keep-loops;no-hoist-common-insts;no-sink-common-insts>),verify,BitcodeWriterPass

At the moment this is best-effort only and there are some known
limitations:
- Not all passes accepting parameters will print their parameters
  (currently only implemented for simplifycfg).
- Some ClassName to pass-name mappings are not unique.
- Some ClassName to pass-name mappings are missing (e.g.
  BitcodeWriterPass).

[libc++][nfc] Fixes ppc64le-sanitizer build issue.

After landing D103357 the worker ppc64le-sanitizer fails on `__bool`.
This replaces all occurrences with `__boolean`.

[DAGCombine] Add node level checks for fp-contract and fp-ninf in visitFMULForFMADistributiveCombine().

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

Fix missing argument introduced by D108788

Reviewed By: aeubanks

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

[test] Precommit/fix up existing test for MemorySSA/invariant.group

[libomptarget] Move HostDataToTargetTy states into StatesTy

Use unique_ptr to achieve the effect of mutable.

Remove mutable keyword of DynRefCount and HoldRefCount
Remove std::shared_ptr from UpdateMtx

Reviewed By: tianshilei1992, grokos

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

[NFC][PowerPC] Small code refactor in LoopInstrFormPrep

Avoid some duplicate code.

Reviewed By: #powerpc, shchenz

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

[CSSPGO] Add stats for pre-inliner

Add some stats to help tuning pre-inliner.

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

[InstrProfiling] Add AIX triple to more tests

Following patch of https://reviews.llvm.org/D108490.
Add AIX triples to tests in /Instrumentation/InstrProfiling/ to make
sure we can catch regressions earlier.

Reviewed By: MaskRay

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

[AArch64][test] Add new tests for (mul (add x, c0), c1)

Reviewed By: dmgreen

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

Reland [MemorySSA] Add pass to print results of MemorySSA walker

Reviewed By: asbirlea

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

Revert "[MemorySSA] Add pass to print results of MemorySSA walker"

This reverts commit 8f98477c2d2bcbf5b6aa36278b59bf2a861426a1.

Breaks bots

[PowerPC] small code format refactor ; NFC

address the code review comments in patch https://reviews.llvm.org/D105872

[MemorySSA] Add pass to print results of MemorySSA walker

Reviewed By: asbirlea

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

PR50294: Fix a performance regression from 2c9dbcd.

Per the contract of ReadLateParsedTemplates, we should not be returning
the same results multiple times. No functionality change intended, other
than to runtime.

Thanks to Luboš Luňák for identifying the cause of the regression!

[OpenMP] Fix -Wunused-but-set-parameter in -DLLVM_ENABLE_ASSERTIONS=off builds. NFC

[HeaderSearch] Use `isImport` only for imported headers and not for `#pragma once`.

There is a separate field `isPragmaOnce` and when `isImport` combines
both, it complicates HeaderFileInfo serialization as `#pragma once` is
the inherent property of the header while `isImport` reflects how other
headers use it. The usage of the header can be different in different
contexts, that's why `isImport` requires tracking separate from `#pragma once`.

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

Revert "snapshot - do not push"

This reverts commit 91f4655d9273ecefab1b7f0ea26d44f5de6fd0af.

This wasn't intented to be pushed, sorry.

Fix a missing MemorySSA update in breakLoopBackedge

This is a case I'd missed in 6a8237. The odd bit here is that missing the edge removal update seems to produce MemorySSA which verifies, but is still corrupt in a way which bothers following passes. I wasn't able to reduce a single pass test case, which is why the reported test case is taken as is.

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

snapshot - do not push

[mlir][sparse] sparse runtime support library improvements

(1) renamed SparseTensor to SparseTensorCOO, the other one remains SparseTensorStorage to focus on contrast

(2) documents difference between public API exclusively for compiler-generated code and methods that could be used by other runtimes (TBD) that want to interact with MLIR

Reviewed By: bixia

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

Revert "[AArch64][GlobalISel] Legalize bswap <2 x i16>"

This reverts commit 5cd63e9ec2a385de2682949c0bbe928afaf35c91.

https://bugs.llvm.org/show_bug.cgi?id=51707

The sequence feeding in/out of the rev32/ushr isn't quite right:

 _swap:
         ldr     h0, [x0]
         ldr     h1, [x0, #2]
-        mov     v0.h[1], v1.h[0]
+        mov     v0.s[1], v1.s[0]
         rev32   v0.8b, v0.8b
         ushr    v0.2s, v0.2s, #16
-        mov     h1, v0.h[1]
+        mov     s1, v0.s[1]
         str     h0, [x0]
         str     h1, [x0, #2]
         ret

[mlir][capi] Add NameLoc

Add method to get NameLoc. Treat null child location as unknown to avoid
needing to create UnknownLoc in C API where child loc is not needed.

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

[AMDGPU] Use S_BITCMP1_* to replace AND in optimizeCompareInstr

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

[AMDGPU] Introduce optimizeCompareInstr

The following patterns are currently handled:

s_cmp_eq_u32 (s_and_b32 $src, 1), 1 => s_and_b32 $src, 1
s_cmp_eq_i32 (s_and_b32 $src, 1), 1 => s_and_b32 $src, 1
s_cmp_eq_u64 (s_and_b64 $src, 1), 1 => s_and_b64 $src, 1
s_cmp_ge_u32 (s_and_b32 $src, 1), 1 => s_and_b32 $src, 1
s_cmp_ge_i32 (s_and_b32 $src, 1), 1 => s_and_b32 $src, 1
s_cmp_lg_u32 (s_and_b32 $src, 1), 0 => s_and_b32 $src, 1
s_cmp_lg_i32 (s_and_b32 $src, 1), 0 => s_and_b32 $src, 1
s_cmp_lg_u64 (s_and_b64 $src, 1), 0 => s_and_b64 $src, 1
s_cmp_gt_u32 (s_and_b32 $src, 1), 0 => s_and_b32 $src, 1
s_cmp_gt_i32 (s_and_b32 $src, 1), 0 => s_and_b32 $src, 1

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

[MemorySSAUpdater] Simplify updates when only deleting edges.

When performing only edge deletion, we don't need to do the DT updates
back and forth. Check for the existance of insert updates to simplify
this.

[OpenMP][AMDGPU] Remove unneeded XFAILs

[Codegen][TLI][X86] SimplifyMultipleUseDemandedBits(): 0'th vec subreg widening is free, try to perform it earlier

I believe, the profitability reasoning here is correct
"sub"reg is already located within the 0'th subreg of wider reg,
so if we have suvector insertion at index 0 into undef,
then it's always free do to.

After this, D109065 finally avoids the regression in D108382.

Reviewed By: RKSimon

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

[InstrProfiling] Use llvm.compiler.used if applicable for Mach-O

Similar to D97585.

D25456 used `S_ATTR_LIVE_SUPPORT` to ensure the data variable will be retained
or discarded as a unit with the counter variable, so llvm.compiler.used is
sufficient. It allows ld to dead strip unneeded profc and profd variables.

Reviewed By: vsk

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

[llvm-profdata] Fix assertion from invalid iterator

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

[RISCV] Fix typo in RISCVSchedSiFive7.td

Fix typo in "microarchitecure".

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

[ARM] Add MVE lowering for fptosi.sat

This adds lowering of the llvm.fptosi.sat and llvm.fptoui.sat intinsics,
selecting a VCVT instruction which under MVE will inherently perform the
saturate.

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

[OpenMP] Use IsHostPtr where needed in rest of omptarget.cpp

As started in D107925, this patch replaces the remaining occurrences
of `UNIFIED_SHARED_MEMORY && TgtPtrBegin == HstPtrBegin` in
`omptarget.cpp` with `IsHostPtr`.  The former condition is broken in
the rare case that the device and host happen to use the same address
for their mapped allocations.  I don't know how to write a test that's
likely to reveal this case.

Reviewed By: grokos

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

[OpenMP] Use IsHostPtr where needed for targetDataBegin

As discussed in D105990, without this patch, `targetDataBegin`
determines whether to transfer data (as opposed to assuming it's in
shared memory) using the condition `!UseUSM || HasCloseModifier`.
However, this condition is broken if use of discrete memory was forced
by `omp_target_associate_ptr`.  This patch extends
`unified_shared_memory/associate_ptr.c` to reveal this case, and it
fixes it using `!IsHostPtr` in `DeviceTy::getTargetPointer` to replace
this condition.

Reviewed By: grokos

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

[OpenMP][NFC] Eliminate CopyMember from targetDataEnd

This patch is based on comments in D105990.  It is NFC according to
the following observations:

1. `CopyMember` is computed as `!IsHostPtr && IsLast`.
2. `DelEntry` is true only if `IsLast` is true.

We apply those observations in order:

```
if ((DelEntry || Always || CopyMember) && !IsHostPtr)

if ((DelEntry || Always || IsLast) && !IsHostPtr)

if ((Always || IsLast) && !IsHostPtr)
```

Reviewed By: grokos

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

[OpenMP] Use IsHostPtr where needed for targetDataEnd

As discussed in D105990, without this patch, `targetDataEnd`
determines whether to transfer data or delete a device mapping (as
opposed to assuming it's in shared memory) using two different
conditions, each of which is broken for some cases:

1. `!(UNIFIED_SHARED_MEMORY && TgtPtrBegin == HstPtrBegin)`: The
   broken case is rare: the device and host might happen to use the
   same address for their mapped allocations.  I don't know how to
   write a test that's likely to reveal this case, but this patch does
   fix it, as discussed below.
2. `!UNIFIED_SHARED_MEMORY || HasCloseModifier`: There are at least
   two broken cases:
    1. The `close` modifier might have been specified on an `omp
      target enter data` but not the corresponding `omp target exit
      data`, which thus might falsely assume a mapping is in shared
      memory.  The test `unified_shared_memory/close_enter_exit.c`
      already has a missing deletion as a result, and this patch adds
      a check for that.  This patch also adds the new test
      `close_member.c` to reveal a missing transfer and deletion.
    2. Use of discrete memory might have been forced by
      `omp_target_associate_ptr`, as in the test
      `unified_shared_memory/api.c`.  In the current `targetDataEnd`
      implementation, this condition turns out not be used for this
      case: because the reference count is infinite, a transfer is
      possible only with an `always` modifier, and this condition is
      never used in that case.  To ensure it's never used for that
      case in the future, this patch adds the test
      `unified_shared_memory/associate_ptr.c`.

Fortunately, `DeviceTy::getTgtPtrBegin` already has a solution: it
reports whether the allocation was found in shared memory via the
variable `IsHostPtr`.

After this patch, `HasCloseModifier` is no longer used in
`targetDataEnd`, and I wonder if the `close` modifier is ever useful
on an `omp target data end`.

Reviewed By: grokos

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

[OpaquePtr] Cleanup some uses of getPointerElementType() in TailRecursionElimination

[InstrProfiling][test] Combine profiling.ll and linkage.ll

The latter mostly covers the former.

[SCEV] Clarify requirements for zero-stride to be UB

There's a silent bug in our reasoning about zero strides. We assume that having a single static exit implies that if that exit is not taken, then the loop must be infinite. This ignores the potential for abnormal exits via exceptions. Consider the following example:

for (uint_8 i = 0; i < 1; i += 0) {
  throw_on_thousandth_call();
}

Our reasoning is such that we'd conclude this loop can't take the backedge as that would lead to a (presumed) infinite loop.

In practice, this is a silent bug because the loopIsFiniteByAssumption returns false strictly more often than the loopHaNoAbnormalExits property. We could reasonable want to change that in the future, so fixing the codeflow now is worthwhile.

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

[openmp] Drop test from D109057, disproportionately difficult to run on windows

 [AMDGPU] enable scalar compare in truncate selection

Currently, the truncate selection dag node is expanded as a bitwise AND plus compare to 1.  This change enables scalar comparison in the pattern if the truncate node is uniform.

Reviewed By: rampitec

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

[LoopDeletion] Separate logic in breakBackedgeIfNotTaken using symboic max trip count [nfc]

As mentioned in D108833, the logic for figuring out if a backedge is dead was somewhat interwoven with the SCEV based logic and the symbolic eval logic. This is my attempt at making the code easier to follow.

Note that this is only NFC after the work done in 29fa37ec.  Thanks to Nikita for catching that case.

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

[openmp] Accept directory for libomptarget-bc-path

The commandline flag to specify a particular openmp devicertl library
currently errors like:
```
fatal error: cannot open file
      './runtimes/runtimes-bins/openmp/libomptarget':
      Is a directory
```
CommonArgs successfully appends the directory to the commandline args then
mlink-builtin-bitcode rejects it.

This patch is a point fix to that. If --libomptarget-amdgcn-bc-path=directory
then append the expected name for the current architecture and go on as before.
This is useful for test runners that don't hardcode the architecture.

Reviewed By: jdoerfert

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

[WebAssembly] Support opaque pointers in FixFunctionBitcasts

With opaque pointers, no actual bitcasts will be present. Instead,
there will be a mismatch between the call FunctionType and the
function ValueType. Change the code to collect CallBases
specifically (rather than general Uses) and compare these types.

RAUW is no longer performed, as there would no longer be any
bitcasts that can be RAUWd.

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

[lld][Hexagon] Add checks for instructions that can have TLS relocations

Several instructions with potential TLS relocations were missing.  This
issue was found when building the Canadian LLVM toolchain.

[mlir][SPIRV] Add Image Operands for Image Instructions

This patch is to add Image Operands in SPIR-V Dialect and also let ImageDrefGather to use Image Operands.

Image Operands are used in many image instructions. "Image Operands encodes what oprands follow, as per Image Operands". And ususally, they are optional to image instructions.

The format of image operands looks like:

    %0 = spv.ImageXXXX %1, ... %3 : f32 ["Bias|Lod"](%4, %5 : f32, f32) -> ...

This patch doesn’t implement all operands (see Section 3.14 in SPIR-V Spec) but provides a skeleton of it. There is TODO in verifyImageOperands function.

Co-authored: Alan Liu <alanliu.yf@gmail.com>

Reviewed by: antiagainst

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

[SCEVExpander] Prefer pointer expansion for overflow checks

We'd special cased this logic to use pointer types for non-integral pointers, but there's no reason we can't do that for all pointer types.   Doing it this was has a few advantages:
a) The code itself becomes more straight forward, and easier to test.
b) We avoid introducing ptrtoint into programs which didn't have them in the source.
c) The resulting codegen is easier to analyze and simplify (mostly due to lack of ptrtoint).

Note that there are some test diffs, but a) running them through instcombine helps a ton, and b) there's enough missing obvious transforms on both before and after IR that it's clear this isn't performance sensitive.

This is mostly motivated by cleaning up mentions of non-integrals to have a clearer idea of what we actually need to support.

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

[AMDGPU] Update Call Convention docs for GFX90A

Document the CSR AGPRs for GFX90A.

Remove the TODO for gfx908, as the answer is that we don't mark any
AGPRs as callee-saved except for GFX90A, i.e. the docs as-is are correct
for gfx908.

Reviewed By: rampitec

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

VFS: Document goals of 'use-external-name' and related logic, NFC

Document 'use-external-name' and the various bits of logic that make it
work, to avoid others having to repeat the archival work (given that I
added getFileRefReturnsCorrectNameForDifferentStatPath to
FileManagerTest, seems possible I understood this once before!).

- b59cf679e81483cbb3a9252056b7528f4c49586c added 'use-external-name' to
  RedirectingFileSystem. This causes `stat`s to return the external
  name for a redirected file instead of the name it was accessed by,
  leaking it through the VFS.
- d066d4c849be06a01c0d17e8dc206913f4e7bfe3 propagated the external name
  further through clang::FileManager.
- 4dc5573acc0d2e7c59d8bac2543eb25cb4b32984, which added
  clang::FileEntryRef to clang::FileManager, has complicated concession
  to account for this as well (since refactored a bit).

The goal of 'use-external-name' is to enable Clang to report "real" file
paths to users (via diagnostics) and to external tools (such as
debuggers reading debug info and build systems reading `.d` files).

I've added FIXMEs to look at other channels for communicating the
external names, since the current implementation adds complexity to
FileManager and exposes an inconsistent interface to clients.

Besides that, the FileManager logic appears to be kicking in outside of
'use-external-name'. Seems that *some* vfs::FileSystem implementations
canonicalize some paths returned by `stat` in *some* cases (the bug
isn't fully understood yet). Volodymyr Sapsai is investigating, this at
least better documents what *is* understood.

Revert "[openmp] Accept directory for libomptarget-bc-path"

Windows separator problem. Fixing that broke another regex.
This reverts commit 0173e024fd9e779a94503040a532bcf125277f86.

Revert "[openmp] No longer use LIBRARY_PATH to find devicertl"

This reverts commit 7a228f872fbbefa6a6eba1d51da192761879fcca.
Failing test case under CI

[libc] Add a skeleton for C standard condition variable functions.

This patch adds a skeleton as a preparatory step for the next patch which
adds the actual implementations of the condition variable functions.

Reviewed By: michaelrj

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

[RISCV] Fold (RISCVISD::SELECT_CC X, Y, CC, Z, Z) -> Z.

If the true and false values are the same, we don't need a SELECT_CC.

This would normally be folded before a select is legalized to
select_cc. The test case exploits the late legalization of vscale
to trigger a case where they become identical after legalization.

This works around an issue found on a test case in D107957. In that
case the true/false values were both eventually 0 and the select was
used by a vector AVL operand. The select_cc got expanded to control
flow and a phi, but the phi inputs were both copies from X0. MachineIR
optimizations simplified this to a single copy from X0 going into the
vector instruction. This became the input of a vsetvli after vsetvli
insertion. Then register coalescing folded the copy into the vsetvli.
X0 as the source of a vsetvli is a special encoding and should not be
created by coalesing. We need to fix our vsetvli handling to make sure
this can never happen any other way, but removing the unneeded select
is still a worthwhile optimization.

[ubsan] warn inside the sigaction interceptor if static linking is suspected, and continue instead of crashing on null deref

[ubsan] warn inside the sigaction interceptor if static linking is suspected, and continue instead of crashing on null deref

Reviewed By: kostik

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

[libomptarget] Drop path separator from test to fix windows build

[openmp] No longer use LIBRARY_PATH to find devicertl

Given D109057, change test runner to use the libomptarget-x-bc-path
argument instead of the LIBRARY_PATH environment variable to find the device
library.

Also drop the use of LIBRARY_PATH environment variable as it is far
too easy to pull in the device library from an unrelated toolchain by accident
with the current setup. No loss in flexibility to developers as the clang
commandline used here is still available.

Reviewed By: jdoerfert

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

[CSSPGO] Sort function offset table to speed up profile loading.

With the context split work, the context-based (an array of strings) sorting performed at profile load time is way more expansive than single-string-based sorting. This is likely due to auxiliary operations done on each array element, such as indirect references, std::min operations, also likely cache misses. In this change I'm presorting profiles during profile generation time to avoid sorting at compile time.

Compared to the previous context-split work, this effectively cuts down compile time by 20% for one of our large services and brings us closer to non-CS build, with still a small gap in build time.

Reviewed By: wenlei, wmi

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

[IVDescriptors] Make pointer inductions compatible with opaque pointers

Store the used element type in the InductionDescriptor. For typed
pointers, it remains the pointer element type. For opaque pointers,
we always use an i8 element type, such that the step is a simple
offset.

A previous version of this patch instead tried to guess the element
type from an induction GEP, but this is not reliable, as the GEP
may be hidden (see @both in iv_outside_user.ll).

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

[libc] Mark return value of memcpy in strcpy as initialized for msan.

Reviewed By: michaelrj

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