[mlir][linalg] Update Linalg.md (NFC).

Update the paragraph on generic / indexed_generic to reflect the unification of these operations.

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

[CSSPGO][llvm-profgen] Change default cold threshold for context merging

llvm-profgen uses profile summary based cold threshold to merge and trim cold context profile. This is to strike a good balance between profile size and performance.

We've been using 99.9% as the cutoff to save profile size without affecting performance. This change switch to use 99.9% instead of 99.9999% as default cold threshold cutoff for llvm-profgen.

Redundant switch csprof-cold-thres is also removed and tests cleaned up.

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

[flang] Fix recent regression (proc. dummy arg on ENTRY)

A recent fix for problems with ENTRY statement handling didn't
get the case of a procedure dummy argument on an ENTRY statement
in an executable part right; the code presumed that those dummy
arguments would be objects, not entities that might be objects or
procedures.  Fix.

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

[AMDGPU][GlobalISel] Stop foldInsertEltToCmpSelect from changing reg banks

This function can change regbank for registers which already have a selected
bank. Depending on the instruction where these registers were used it can
cause instruction selection to fail.

[InstCombine] avoid infinite loop from vector select transforms

The 2nd test is based on the fuzzer example in post-commit
comments of D101191 -
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=34661

The 1st test shows that we don't deal with this symmetrically.
We should be able to reduce both examples (possibly in
instsimplify instead of instcombine).

Revert "[OpaquePtr] Make atomicrmw work with opaque pointers"

This reverts commit 0bebda17bea38785c90a6fec3ca01cf74eb78b7c.

Causing "Invalid record" errors.

[SCEV] Cleanup doesIVOverflowOnX checks [NFC]

Stylistic changes only.
1) Don't pass a parameter just to do an early exit.
2) Use a name which matches actual behavior.

[llvm-reduce] Exit when input module is malformed

The parseInputFile function returns an empty unique_ptr to signal an
error, like when the input file doesn't exist, or is malformed. In this
case, the tool should exit immediately rather than segfault by
dereferencing the unique_ptr later.

Reviewed By: aeubanks

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

[SCEV] Remove unused parameter from computeBECount [NFC]

All callers pass "false" for the Equality parameter.  Kill the dead code, and update the function block comment.

[libc++] Try to fix the oss-fuzz failure

[sparse][mlir] simplify sparse runtime support library

Removed some of the older raw "MLIRized" versions that are
no longer needed now that the sparse runtime support library
can focus on the proper sparse tensor types rather than the
opague pointer approach of the past. This avoids legacy...

Reviewed By: penpornk

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

[AIX][AsmPrinter] Print Symbol in comments for TOC load

We are using TOCEntry symbols like `LC..0` in TOC loads,
this is hard to read , at least requiring an additional step to figure
out the loaded symbols.

We should print out the name in comments.

Reviewed By: #powerpc, shchenz

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

[X86][Atom] Fix vector PSHUFB resource/throughputs

Match whats documented in the Intel AOM - the XMM variant of PSHUFB requires BOTH ports - this was being incorrectly modelled as EITHER port.

Now that we can use in-order models in llvm-mca, the atom model is a good "worst case scenario" analysis for x86.

[CostModel][X86] Improve accuracy of 256-bit non-uniform vector shifts on AVX1

Determined from llvm-mca analysis, AVX1 capable targets have a higher throughput for VPBLENDVB and shuffle ops, making it cheaper to perform shift+shuffle/select shift patterns.

[VectorCombine] Remove unneeded InsertPointGuard (NFCI).

All users of the builder should set an insert point before using the
builder. There should be no need for using InsertPointGuard here.

[mlir][CAPI][test] Change casts and fprintf format strings from long to intptr_t

A test in ir.c makes use of casting a void* to an integer type to print it's address. This cast is currently done with the datatype `long` however, which is only guaranteed to be equal to the pointer width on LP64 system. Other platforms may use a length not equal to the pointer width. 64bit Windows as an example uses 32 bit for `long` which does not match the 64 bit pointers.
This also results in clang warning due to `-Wvoid-pointer-to-int-cast`.

Technically speaking, since the test only passes the value 42, it does not cause any issues, but it'd be nice to fix the warning at least.

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

[scudo] Rework dieOnMapUnmapError

Said function had a few shortfalls:
- didn't set an abort message on Android
- was logged on several lines
- didn't provide extra information like the size requested if OOM'ing

This improves the function to address those points.

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

[SystemZ] Return true from preferZeroCompareBranch().

Review: Ulrich Weigand
Differential Revision: https://reviews.llvm.org/D103057

BPF: Add more relocation kinds

Currently, BPF only contains three relocations:
  R_BPF_NONE   for no relocation
  R_BPF_64_64  for LD_imm64 and normal 64-bit data relocation
  R_BPF_64_32  for call insn and normal 32-bit data relocation

Also .BTF and .BTF.ext sections contain symbols in allocated
program and data sections. These two sections reserved 32bit
space to hold the offset relative to the symbol's section.
When LLVM JIT is used, the LLVM ExecutionEngine RuntimeDyld
may attempt to resolve relocations for .BTF and .BTF.ext,
which we want to prevent. So we used R_BPF_NONE for such relocations.

This all works fine until when we try to do linking of
multiple objects.
  . R_BPF_64_64 handling of LD_imm64 vs. normal 64-bit data
    is different, so lld target->relocate() needs more context
    to do a correct job.
  . The same for R_BPF_64_32. More context is needed for
    lld target->relocate() to differentiate call insn vs.
    normal 32-bit data relocation.
  . Since relocations in .BTF and .BTF.ext are set to R_BPF_NONE,
    they will not be relocated properly when multiple .BTF/.BTF.ext
    sections are merged by lld.

This patch intends to address this issue by adding additional
relocation kinds:
  R_BPF_64_ABS64     for normal 64-bit data relocation
  R_BPF_64_ABS32     for normal 32-bit data relocation
  R_BPF_64_NODYLD32  for .BTF and .BTF.ext style relocations.
The old R_BPF_64_{64,32} semantics:
  R_BPF_64_64        for LD_imm64 relocation
  R_BPF_64_32        for call insn relocation

The existing R_BPF_64_64/R_BPF_64_32 mapping to numeric values
is maintained. They are the most common use cases for
bpf programs and we want to maintain backward compatibility
as much as possible.

ExecutionEngine RuntimeDyld BPF relocations are adjusted as well.
R_BPF_64_{ABS64,ABS32} relocations will be resolved properly and
other relocations will be ignored.
Two tests are added for RuntimeDyld. Not handling R_BPF_64_NODYLD32 in
RuntimeDyldELF.cpp will result in "Relocation type not implemented yet!"
fatal error.

FK_SecRel_4 usages in BPFAsmBackend.cpp and BPFELFObjectWriter.cpp
are removed as they are not triggered in BPF backend.
BPF backend used FK_SecRel_8 for LD_imm64 instruction operands.

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

[SystemZ][z/OS] Implement getHostCPUName for z/OS

- Currently, the host cpu information is not easily available on z/OS as in other platforms.
- This information is stored in the Communications Vector Table (https://www.ibm.com/docs/en/zos/2.2.0?topic=information-cvt-mapping)

Reviewed By: uweigand

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

[libc++] [test] Make iter_difference_t.pass.cpp into a .compile.pass.cpp. NFCI.

[libc++] [test] Format some C++20 iterator_traits tests. NFCI.

cxx20_iterator_traits.compile.pass.cpp actually depends on
implementation details of libc++, which is not great;
but I just left a comment and moved on.

[AMDGPU] Allow no-modifier operands in cvtDPP

NFC, since no instructions have their AsmMatchConverter
changed, but prepares for that to happen.

Reviewed By: rampitec

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

Change-Id: I6afefad899076de7b9a412374d09b95b29e012fa

[CostModel][X86] Improve accuracy of vXi64 vector non-uniform shift costs on AVX2+ targets

rG1ad4f887bd7692a9e63fb42586f0ece366f2fe01 incorrectly assumed that vXi64 non-uniform shifts were slow like vXi32 were - but llvm-mca (+Agner) both confirm that Haswell/Broadwell are full rate.

[X86][SSE] Regenerate vector shift codegen tests. NFCI.

Reland "Do not create LLVM IR `constant`s for objects with dynamic initialisation"

This relands commit 13dd65b3a1a3ac049b5f3a9712059f7c61649bea.

The original commit contained a test, which failed when compiled
for a MACH-O target.

This patch changes the test to run for x86_64-linux instead of
`%itanium_abi_triple`, to avoid having invalid syntax for MACH-O
sections. The patch itself does not care about section attribute
syntax and a x86 backend does not even need to be included in the
build.

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

[clang][ARM] When handling multiple -mimplicit-it mark all as used

Since 4468e5b8999291cc84b78f33f207dcd0e58146bc clang will prefer
the last one it finds of "-mimplicit-it" or "-Wa,-mimplicit-it".

Due to a mistake in that patch the compiler argument "-mimplicit-it"
was never marked as used, even if it was the last one and was passed
to llvm.

Move the Claim call back to the start of the loop and update
the testing to check we don't get any unused argument warnings.

Reviewed By: mstorsjo

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

[AMDGPU] More accurate names for dpp operand types

NFC. Renames the variable in the dpp input operand generators
from DstRC to OldRC, because that is what it actually sets.

Also documents the importance of setting HasModifiers = 0 in the
dpp8 asm string.

Reviewed By: arsenm

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

Change-Id: Ice69ae38f644de7f228a75ca47c43e88b1f7d9e1

[InstSimplify] Transform X * Y % Y --> 0

simplifyDiv already handles the case X * Y / Y --> X (barring overflow).
This adds the equivalent handling to simplifyRem.

Correctness:
https://alive2.llvm.org/ce/z/J2cUbS
https://alive2.llvm.org/ce/z/us9NUM
https://alive2.llvm.org/ce/z/AvaDGJ
https://alive2.llvm.org/ce/z/kq9ige

Extending the situations in which we apply this transform would not be
correct:
https://alive2.llvm.org/ce/z/Lf9V63
https://alive2.llvm.org/ce/z/6RPQK3
https://alive2.llvm.org/ce/z/p9UdxC
https://alive2.llvm.org/ce/z/A2zlhE
https://alive2.llvm.org/ce/z/vHTtLw
https://alive2.llvm.org/ce/z/lvpH42

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

[VectorCombine] Add test that combines load & store scalarization.

[Headers][WASM] adjust test that runs the optimizer; NFC

This broke with the LLVM change in 0bab0f616119

[VectorCombine] Use constant range info for index scalarization legality.

We can only scalarize memory accesses if we know the index is valid.

This patch adjusts canScalarizeAcceess to fall back to
computeConstantRange to check if the index is known to be valid.

Reviewed By: nlopes

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

[mlir][doc] Fix links and references in documentation of Dialects

This patch is the first in a series of patches fixing markdown links and references inside the mlir documentation. I chose to split it in a few reviews to be able to iterate quicker and to ease review.

This patch addresses all broken references to other markdown files and sections inside the Dialects folder.

One change that was also done was to insert '/' between the markdown files and section:
Example:
Builtin.md#integertype
was changed to:
Builtin.md/#integertype

After compilation, hugo then translates the later to jump directly to the integer type section, but not the former. Not inserting the slash would simply jump to just the Builtin page, instead of the integertype section. I therefore changed occurrences of the former version to the later as well.

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

[mlir] Support buffer hoisting on allocas

This adds support for hoisting allocas in both BufferHoisting and
BufferLoopHoisting.

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

[mlir][doc] Fix links and references in documentation of Rationale

This patch is the second in a series of patches fixing markdown links and references inside the mlir documentation.

This patch addresses all broken references to other markdown files and sections inside the Rationale folder.

In addition to fixing the links and references like in the previous patch, I also changed references which are URLs to the mlir.llvm.org/docs website, to proper relative markdown references instead.

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

[InstCombine] canonicalize cast before unary shuffle

We could go either direction on this transform. VectorCombine already goes this
way for bitcasts (and handles more complicated cases using the cost model), so
let's try cast-first.

Deferring completely to VectorCombine is another possibility. But the backend
should be able to invert this easily when the vectors have the same shape, so
it doesn't seem like a transform that we need to avoid.

The motivating example from https://llvm.org/PR49081 has an int-to-float
sandwiched between 2 shuffles, and the backend currently does not reduce that,
so on x86, we get something like:

  pshufd $249, %xmm0, %xmm0]
  cvtdq2ps %xmm0, %xmm0
  shufps $144, %xmm0, %xmm0

...instead of just a single conversion instruction.

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

[InstCombine] add tests for cast-of-shuffle; NFC

[mlir] Disallow certain transfer ops in VectorToSCF

Disallow transfer ops that change the element type of the transfer. Such transfers could be supported in the future, if needed.

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

[Dexter] Remove erroneously added diff file

Delete d.diff from debuginfo-tests/dexter directory.

[NFC] [Coroutines] Remove unused variable: UnreachableCache

[dexter] Change --source-root-dir and add --debugger-use-relative-paths

We want to use `DexDeclareFile` to specify paths relative to a project root
directory. The option `--source-root-dir`, prior to this patch, causes dexter
to strip the path prefix from commands before passing them to a debugger, and
appends the prefix to file paths returned from a debugger. This patch changes
the behviour of `--source-root-dir`. Relative paths in commands, made possible
with `DexDeclareFile(relative/path)`, are appended to the `--source-root-dir`
directory.

A new option, `--debugger-use-relative-paths`, can be used alongside
`--source-root-dir` to reproduce the old behaviour: all paths passed to the
debugger will be made relative to `--source-root-dir`.

I've added a regression test source_root_dir.dex for this new behaviour, and
modified the existing `--source-root-dir` regression and unit tests to use
`--debugger-use-relative-paths`.

Reviewed By: jmorse

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

[LoopIdiom] Support 'left-shift until zero' idiom

This adds support for the "count active bits" pattern, i.e.:
```
int countBits(unsigned val) {
    int cnt = 0;
    for( ; (val << cnt) != 0; ++cnt)
        ;
    return cnt;
}
```
but a somewhat more general one:
```
int countBits(unsigned val, int start, int off) {
    int cnt;
    for (cnt = start; val << (cnt + off); cnt++)
        ;
    return cnt;
}
```

alive2 is happy with all the tests there.

Note that, again, much like with the right-shift cases,
we don't require the `val != 0` guard.

This is the last pattern that was supported by
`detectShiftUntilZeroIdiom()`, which now becomes obsolete.

[NFC][LoopIdiom] Add tests for 'left-shift until zero' idiom

[AMDGPU][Libomptarget] Mark lambda_by_value test as XFAIL

Reason: Missing printf definition

Reviewed By: JonChesterfield

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

[AArch64][SVE] Add fixed length codegen for FP_TO_{S,U}INT/{S,U}INT_TO_FP

Depends on D102607

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

[Dexter] Add DexDeclareFile command to Dexter

DexDeclareFile allows test producers to write test files with .dex extensions
that contain pure dexter commands.

.dex file commands do not need to be commented out like they do when written
inline within test source files.

DexDeclareFile commands are declarative in behaviour, they state that any
Dexter command seen from this point on will have its path attribute set to the
path declared in the DexDeclareFile command.

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

[lldb] Fix that LLDB doesn't print NaN's sign on Darwin

It seems std::ostringstream ignores NaN signs on Darwin while it prints them on
Linux. This causes that LLDB behaves differently on those platforms which is
both confusing for users and it also means we have to deal with that in our
tests.

This patch manually implements the NaN/Inf printing (which are apparently
implementation defined) to make LLDB print the same thing on all platforms. The
only output difference in practice seems to be that we now print negative NaNs
as `-nan`, but this potentially also changes the output on other systems I
haven't tested this on.

Reviewed By: JDevlieghere

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

[LoopIdiom] Support 'arithmetic right-shift until zero' idiom

This adds support for the "count active bits" pattern, i.e.:
```
int countActiveBits(signed val) {
    int cnt = 0;
    for( ; (val >> cnt) != 0; ++cnt)
        ;
    return cnt;
}
```
but a somewhat more general one:
```
int countActiveBits(signed val, int start, int off) {
    int cnt;
    for (cnt = start; val >> (cnt + off); cnt++)
        ;
    return cnt;
}
```

This directly matches the existing 'logical right-shift until zero' idiom.
alive2 is happy with all the tests there.

Note that, again, much like with the original unsigned case,
we don't require the `val != 0` guard.

The old `detectShiftUntilZeroIdiom()` already supports this pattern,
the idea here is that the `val` must be positive (have at least one
leading zero), because otherwise the loop is non-terminating,
but since it is not `while(1)`, that would have been UB.

[NFC][LoopIdiom] Add tests for 'arithmetic right-shift until zero' idiom

[lldb][NFC] Remove misleading ModulePass base class for IRForTarget

IRForTarget is never used by a pass manager or any other interface that requires
this class to inherit from `Pass`.

Also IRForTarget doesn't implement the current interface correctly because it
uses the `runOnModule` return value to indicate success/failure instead of
changed/not-changed, so if this ever ends up being used as a pass it would most
likely not work as intended.

Reviewed By: JDevlieghere

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

[lldb] X-FAIL TestCPPStaticMembers on Windows

This was originally failed because of llvm.org/pr21765 which describes that
LLDB can't call a debugee's functions, but I removed the (unnecessary)
function call in the rewrite. It seems that the actual bug here is that we
can't lookup static members at all, so let's X-FAIL the test for the right
reason.

[SanitizeCoverage] Add support for NoSanitizeCoverage function attribute

We really ought to support no_sanitize("coverage") in line with other
sanitizers. This came up again in discussions on the Linux-kernel
mailing lists, because we currently do workarounds using objtool to
remove coverage instrumentation. Since that support is only on x86, to
continue support coverage instrumentation on other architectures, we
must support selectively disabling coverage instrumentation via function
attributes.

Unfortunately, for SanitizeCoverage, it has not been implemented as a
sanitizer via fsanitize= and associated options in Sanitizers.def, but
rolls its own option fsanitize-coverage. This meant that we never got
"automatic" no_sanitize attribute support.

Implement no_sanitize attribute support by special-casing the string
"coverage" in the NoSanitizeAttr implementation. To keep the feature as
unintrusive to existing IR generation as possible, define a new negative
function attribute NoSanitizeCoverage to propagate the information
through to the instrumentation pass.

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

Reviewed By: vitalybuka, morehouse

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

[NFC][SanitizeCoverage] Test always_inline functions work

Test that always_inline functions are instrumented as expected.

Reviewed By: vitalybuka

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

[NFC][CodeGenOptions] Refactor checking SanitizeCoverage options

Refactor checking SanitizeCoverage options into
CodeGenOptions::hasSanitizeCoverage().

Reviewed By: vitalybuka

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

Fix MSVC "truncation of constant value" warning. NFCI.

[CostModel][X86] Improve accuracy of vXi8/vXi16 vector non-uniform shift costs on AVX2/AVX512 targets

Determined from llvm-mca analysis, AVX2+ capable targets have a higher throughput for VPBLENDVB and VPMOVZX ops, making it cheaper to perform shift+select patterns for vXi8 shifts or extend/shift/truncate for vXi16 shifts. Similarly AVX512BW can perform vXi8 as extend/shift/truncate patterns.

[AMDGPU] Remove dead declaration (NFC).

[MLIR][Affine][LICM] Mark users of `iter_args` variant

Prevent users of `iter_args` of an affine for loop from being hoisted
out of it. Otherwise, LICM leads to a violation of the SSA dominance
(as demonstrated in the added test case).

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

Reviewed By: bondhugula, ayzhuang

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

[mlir] Fold memref.dim of OffsetSizeAndStrideOpInterface outputs

This previously handled memref::SubviewOp, but this can be extended to
all ops implementing the interface.

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

[AArch64] Add tests for lowering of vector load + single extract.

Currently the vector load + extract gets lowered to a single scalar
store, not accounting for the fact that the index could be
out-of-bounds, which is poison, not UB.

See PR50382.

[lldb] Disable minimal import mode for RecordDecls that back FieldDecls

Clang adds a Decl in two phases to a DeclContext. First it adds it invisible and
then it makes it visible (which will add it to the lookup data structures). It's
important that we can't do lookups into the DeclContext we are currently adding
the Decl to during this process as once the Decl has been added, any lookup will
automatically build a new lookup map and add the added Decl to it. The second
step would then add the Decl a second time to the lookup which will lead to
weird errors later one. I made adding a Decl twice to a lookup an assertion
error in D84827.

In the first step Clang also does some computations on the added Decl if it's
for example a FieldDecl that is added to a RecordDecl.

One of these computations is checking if the FieldDecl is of a record type
and the record type has a deleted constexpr destructor which will delete
the constexpr destructor of the record that got the FieldDecl.

This can lead to a bug with the way we implement MinimalImport in LLDB
and the following code:

```
struct Outer {
  typedef int HookToOuter;
  struct NestedClass {
    HookToOuter RefToOuter;
  } NestedClassMember; // We are adding this.
};
```

1. We just imported `Outer` minimally so far.
2. We are now asked to add `NestedClassMember` as a FieldDecl.
3. We import `NestedClass` minimally.
4. We add `NestedClassMember` and clang does a lookup for a constexpr dtor in
   `NestedClass`. `NestedClassMember` hasn't been added to the lookup.
5. The lookup into `NestedClass` will now load the members of `NestedClass`.
6. We try to import the type of `RefToOuter` which will try to import the `HookToOuter` typedef.
7. We import the typedef and while importing we check for conflicts in `Outer` via a lookup.
8. The lookup into `Outer` will cause the invisible `NestedClassMember` to be added to the lookup.
9. We continue normally until we get back to the `addDecl` call in step 2.
10. We now add `NestedClassMember` to the lookup even though we already did that in step 8.

The fix here is disabling the minimal import for RecordTypes from FieldDecls. We
actually already did this, but so far we only force the definition of the type
to be imported *after* we imported the FieldDecl. This just moves that code
*before* we import the FieldDecl so prevent the issue above.

Reviewed By: shafik, aprantl

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

[lldb] Re-eanble and rewrite TestCPPStaticMembers

It's not clear why the whole test got disabled, but the linked bug report
has since been fixed and the only part of it that still fails is the test
for the too permissive lookup. This re-enables the test, rewrites it to use
the modern test functions we have and splits the failing part into its
own test that we can skip without disabling the rest.

[IR] Allow Value::replaceUsesWithIf() to process constants

The change is currently NFC, but exploited by the depending D102954.
Code to handle constants is borrowed from the general implementation
of Value::doRAUW().

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

[llvm-exegesis] Loop unrolling for loop snippet repetitor mode

I really needed this, like, factually, yesterday,
when verifying dependency breaking idioms for AMD Zen 3 scheduler model.

Consider the following example:
```
$ ./bin/llvm-exegesis --mode=inverse_throughput --snippets-file=/tmp/snippet.s --num-repetitions=1000000 --repetition-mode=duplicate
Check generated assembly with: /usr/bin/objdump -d /tmp/snippet-4a7e50.o
---
mode:            inverse_throughput
key:
  instructions:
    - 'VPXORYrr YMM0 YMM0 YMM0'
  config:          ''
  register_initial_values: []
cpu_name:        znver3
llvm_triple:     x86_64-unknown-linux-gnu
num_repetitions: 1000000
measurements:
  - { key: inverse_throughput, value: 0.31025, per_snippet_value: 0.31025 }
error:           ''
info:            ''
assembled_snippet: C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C5FDEFC0C3
...

```
What does it tell us?
So wait, it can only execute ~3 x86 AVX YMM PXOR zero-idioms per cycle?
That doesn't seem right. That's even less than there are pipes supporting this type of op.

Now, second example:
```
$ ./bin/llvm-exegesis --mode=inverse_throughput --snippets-file=/tmp/snippet.s --num-repetitions=1000000 --repetition-mode=loop
Check generated assembly with: /usr/bin/objdump -d /tmp/snippet-2418b5.o
---
mode:            inverse_throughput
key:
  instructions:
    - 'VPXORYrr YMM0 YMM0 YMM0'
  config:          ''
  register_initial_values: []
cpu_name:        znver3
llvm_triple:     x86_64-unknown-linux-gnu
num_repetitions: 1000000
measurements:
  - { key: inverse_throughput, value: 1.00011, per_snippet_value: 1.00011 }
error:           ''
info:            ''
assembled_snippet: 49B80800000000000000C5FDEFC0C5FDEFC04983C0FF75F2C3
...
```
Now that's just worse. Due to the looping, the throughput completely plummeted,
and now we can only do a single instruction/cycle!?

That's not great.
And final example:
```
$ ./bin/llvm-exegesis --mode=inverse_throughput --snippets-file=/tmp/snippet.s --num-repetitions=1000000 --repetition-mode=loop --loop-body-size=1000
Check generated assembly with: /usr/bin/objdump -d /tmp/snippet-c402e2.o
---
mode:            inverse_throughput
key:
  instructions:
    - 'VPXORYrr YMM0 YMM0 YMM0'
  config:          ''
  register_initial_values: []
cpu_name:        znver3
llvm_triple:     x86_64-unknown-linux-gnu
num_repetitions: 1000000
measurements:
  - { key: inverse_throughput, value: 0.167087, per_snippet_value: 0.167087 }
error:           ''
info:            ''
assembled_snippet: 49B80800000000000000C5FDEFC0C5FDEFC04983C0FF75F2C3
...
```

So if we merge the previous two approaches, do duplicate this single-instruction snippet 1000x
(loop-body-size/instruction count in snippet), and run a loop with 1000 iterations
over that duplicated/unrolled snippet, the measured throughput goes through the roof,
up to 5.9 instructions/cycle, which finally tells us that this idiom is zero-cycle!

Reviewed By: courbet

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

[ARM][NEON] Combine base address updates for vld1x intrinsics

Reviewed By: dmgreen

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

[clang][ARM] Remove non-existent arm9312 CPU

I cannot find documentation on this CPU, and it
is not supported by the Arm Compiler 5 product either.

It was likely a mistake or a different name for the
"ep9312", which is an Arm based Cirrus Logic chip.

Reviewed By: peter.smith

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

[llvm][ARM] Remove non-existent arm1176j-s CPU

This was removed in https://reviews.llvm.org/D52594 for clang.

The one test using it has been updated to use the mpcore
CPU as the linked clang change does.

This is part of fixing https://bugs.llvm.org/show_bug.cgi?id=50454.

Reviewed By: peter.smith

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

[GlobalISel] Silence unused variable warning in Release builds. NFC.

[clang][ARM] Remove non-existent arm1136jz-s CPU

There is an ARM1136JF-S and an ARM1136J-S but I could find
no references to an ARM1136JZ-S. In CPU manuals or the manual
for Arm Compiler 5.

See:
https://developer.arm.com/documentation/ddi0211/latest/
https://developer.arm.com/documentation/dui0472/latest/

Using this CPU you get:
$ ./bin/clang --target=arm-linux-gnueabihf -march=armv3m -mcpu=arm1136jz-s -c /tmp/test.c -o /tmp/test.o
'arm1136jz-s' is not a recognized processor for this target (ignoring processor)

Since the llvm target does not know what it is.

This is part of fixing https://bugs.llvm.org/show_bug.cgi?id=50454.

Reviewed By: peter.smith

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

[mlir] Check only last dim stride in transfer op lowering

Lower a 1D vector transfer op to LLVM if the last dim stride is 1. Also fixes a bug in the original unit stride computation.

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

[TRE] Reland: allow TRE for non-capturing calls.

The D82085 "allow TRE for non-capturing calls" caused failure during bootstrap.
This patch does the same as D82085 plus fixes bootstrap error.

The problem with D82085 is that it does not create copies for byval
operands, while replacing function call with a branch.

Consider following example:

```
    int zoo ( S p1 );

    int foo ( int count, S p1 ) {
      if ( count > 10 )
        return zoo(p1);

      // temporarily variable created for passing byvalue parameter
      // p1 could be used when zoo(p1) is called(after TRE is done).
      // lifetime.start p1.byvalue.temp
      return foo(count+1, p1);
      // lifetime.end p1.byvalue.temp
    }
```

After recursive call to foo is replaced with a jump into
start of the function, its parameters could be passed to
zoo function. i.e. temporarily variable created for byvalue
parameter "p1" could be passed to zoo. Finally zoo receives
broken operand:

```
    int foo ( int count, S p1 ) {
    :tailrecurse
      p1_tr = phi p1, p1.byvalue.temp
      if ( count > 10 )
        return zoo(p1_tr);

      // temporarily variable created for passing byvalue parameter
      // p1 could be used when zoo(p1) is called(after TRE is done).
      lifetime.start p1.byvalue.temp
      memcpy (p1.byvalue.temp, p1_tr)
      count = count + 1
      lifetime.end p1.byvalue.temp
      br tailrecurse
    }
```

To prevent using p1.byvalue.temp after its scope finished by
lifetime.end marker this patch copies value from p1.byvalue.temp
into another temporarily variable and then copies this variable
into the input parameter for next iteration.

This patch passes bootstrap build and bootstrap build with AddressSanitizer.

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

[libomptarget][nfc] Accept callable for hsa iterate_symbols

[libomptarget][nfc] Accept callable for hsa iterate_symbols
Candidate refactor to simplify D102692

Reviewed By: pdhaliwal

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

[analyzer][ctu] Reland "Avoid parsing invocation list again and again..

..during on-demand parsing of CTU"

During CTU, the *on-demand parsing* will read and parse the invocation
list to know how to compile the file being imported. However, it seems
that the invocation list will be parsed again if a previous parsing
has failed.
Then, parse again and fail again. This patch tries to overcome the
problem by storing the error code during the first parsing, and
re-create the stored error during the later parsings.

Reland without test.

Reviewed By: steakhal

Patch By: OikawaKirie!

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

[GlobalISel] Fix MachineIRBuilder not using the DstOp argument for G_SHUFFLE_VECTOR.

Revert "[analyzer][ctu] Avoid parsing invocation list again and again during on-demand parsing of CTU"

This reverts commit db8af0f21dc9aad4d336754c857c24470afe53e3.

clang-x86_64-debian-fast fails on this.

+ : 'RUN: at line 4'
+ /usr/bin/ccache
/b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Analysis/ctu-on-demand-parsing-multiple-invocation-list-parsing.cpp
-fPIC -shared -o
/b/1/clang-x86_64-debian-fast/llvm.obj/tools/clang/test/Analysis/Output/ctu-on-demand-parsing-multiple-invocation-list-parsing.cpp.tmp/mock_open.so
ccache: error: execv of
/b/1/clang-x86_64-debian-fast/llvm.src/clang/test/Analysis/ctu-on-demand-parsing-multiple-invocation-list-parsing.cpp
failed: Permission denied

[analyzer][ctu] Avoid parsing invocation list again and again during on-demand parsing of CTU

During CTU, the *on-demand parsing* will read and parse the invocation
list to know how to compile the file being imported. However, it seems
that the invocation list will be parsed again if a previous parsing
has failed.
Then, parse again and fail again. This patch tries to overcome the
problem by storing the error code during the first parsing, and
re-create the stored error during the later parsings.

Reviewed By: steakhal

Patch By: OikawaKirie!

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

[RISCV] Optimize xor/or with immediate in the zbs extension

Reviewed By: craig.topper

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

[JITLink] Suppress expect-death test in release mode.

[LoopDeletion] Break backedge if we can prove that the loop is exited on 1st iteration

This patch handles one particular case of one-iteration loops for which SCEV
cannot straightforwardly prove BECount = 1. The idea of the optimization is to
symbolically execute conditional branches on the 1st iteration, moving in topoligical
order, and only visiting blocks that may be reached on the first iteration. If we find out
that we never reach header via the latch, then the backedge can be broken.

Differential Revision: https://reviews.llvm.org/D102615
Reviewed By: reames

[Test] Add test for unreachable backedge with duplicating predecessors

AMDGPU/GlobalISel: Legalize G_[SU]DIVREM instructions

Reviewed By: arsenm

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

[JITLink] Enable creation and management of mutable block content.

This patch introduces new operations on jitlink::Blocks: setMutableContent,
getMutableContent and getAlreadyMutableContent. The setMutableContent method
will set the block content data and size members and flag the content as
mutable. The getMutableContent method will return a mutable copy of the existing
content value, auto-allocating and populating a new mutable copy if the existing
content is marked immutable. The getAlreadyMutableMethod asserts that the
existing content is already mutable and returns it.

setMutableContent should be used when updating the block with totally new
content backed by mutable memory. It can be used to change the size of the
block. The argument value should *not* be shared with any other block.

getMutableContent should be used when clients want to modify the existing
content and are unsure whether it is mutable yet.

getAlreadyMutableContent should be used when clients want to modify the existing
content and know from context that it must already be immutable.

These operations reduce copy-modify-update boilerplate and unnecessary copies
introduced when clients couldn't me sure whether the existing content was
mutable or not.

[cfe] Support target-specific escaped character in inline asm

GCC allows each target to define a set of non-letter and non-digit
escaped characters for inline assembly that will be replaced by another
string (They call this "punctuation" characters. The existing "%%" and
"%{" -- replaced by '%' and '{' at the end -- can be seen as special
cases shared by all targets).
This patch implements this feature by adding a new hook in `TargetInfo`.

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

[Sema] Always search the full function scope context if a potential availability violation is encountered

This fixes both https://bugs.llvm.org/show_bug.cgi?id=50309 and https://bugs.llvm.org/show_bug.cgi?id=50310.

Previously, lambdas inside functions would mark their own bodies for later analysis when encountering a potentially unavailable decl, without taking into consideration that the entire lambda itself might be correctly guarded inside an @available check. The same applied to inner class member functions. Blocks happened to work as expected already, since Sema::getEnclosingFunction() skips through block scopes.

This patch instead simply and conservatively marks the entire outermost function scope for search, and removes some special-case logic that prevented DiagnoseUnguardedAvailabilityViolations from traversing down into lambdas and nested functions. This correctly accounts for arbitrarily nested lambdas, inner classes, and blocks that may be inside appropriate @available checks at any ancestor level. It also treats all potential availability violations inside functions consistently, without being overly sensitive to the current DeclContext, which previously caused issues where e.g. nested struct members were warned about twice.

DiagnoseUnguardedAvailabilityViolations now has more work to do in some cases, particularly in functions with many (possibly deeply) nested lambdas and classes, but the big-O is the same, and the simplicity of the approach and the fact that it fixes at least two bugs feels like a strong win.

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

[lld:elf] Weaken the requirement for a computed binding to be STB_LOCAL

Given the following scenario:

```
// Cat.cpp
struct Animal { virtual void makeNoise() const = 0; };
struct Cat : Animal { void makeNoise() const override; };

extern "C" int puts(char const *);
void Cat::makeNoise() const { puts("Meow"); }
void doThingWithCat(Animal *a) { static_cast<Cat *>(a)->makeNoise(); }

// CatUser.cpp
struct Animal { virtual void makeNoise() const = 0; };
struct Cat : Animal { void makeNoise() const override; };

void doThingWithCat(Animal *a);

void useDoThingWithCat() {
  Cat *d = new Cat;
  doThingWithCat(d);
}

// cat.ver
{
  global: _Z17useDoThingWithCatv;
  local: *;
};

$ clang++ Cat.cpp CatUser.cpp -fpic -flto=thin -fwhole-program-vtables
-shared -O3 -fuse-ld=lld -Wl,--lto-whole-program-visibility
-Wl,--version-script,cat.ver
```

We cannot devirtualize `Cat::makeNoise`. The issue is complex:

Due to `-fsplit-lto-unit` and usage of type metadata, we place the Cat
vtable declaration into module 0 and the Cat vtable definition with type
metadata into module 1, causing duplicate entries (Undefined followed by
Defined) in the `lto::InputFile::symbols()` output.
In `BitcodeFile::parse`, after processing the `Undefined` then the
`Defined`, the final state is `Defined`.
In `BitcodeCompiler::add`, for the first symbol, `computeBinding`
returns `STB_LOCAL`, then we reset it to `Undefined` because it is
prevailing (`versionId` is `preserved`). For the second symbol, because
the state is now `Undefined`, `computeBinding` returns `STB_GLOBAL`,
causing `ExportDynamic` to be true and suppressing devirtualization.

In D77280, the `computeBinding` change used a stricter `isDefined()`
condition to make weak``Lazy` symbol work.
This patch relaxes the condition to weaker `!isLazy()` to keep it
working while making the devirtualization work as well.

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

Making Instrumentation aware of LoopNest Pass

Intrumentation callbacks are not made aware of LoopNest passes. From the loop pass manager, we can pass the outermost loop of the LoopNest to instrumentation in case of LoopNest passes.

The current patch made the change in two places in StandardInstrumentation.cpp. I will submit a proper patch where the OuterMostLoop is passed from the LoopPassManager to the call backs. That way we will avoid making changes at multiple places in StandardInstrumentation.cpp.

A testcase also will be submitted.

Reviewed By: aeubanks

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

Revert "[LoopUnrollAndJam] Change LoopUnrollAndJamPass to LoopNest pass"

This reverts commit d65c32fb41b03a35a2a16330ba1ea15cf6818f04.

[libomptarget] [amdgpu] Added LDS usage to the kernel trace

Reviewed By: JonChesterfield

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

Revert "Do not create LLVM IR `constant`s for objects with dynamic initialisation"

This reverts commit 13dd65b3a1a3ac049b5f3a9712059f7c61649bea.
Breaks check-clang on macOS, see https://reviews.llvm.org/D102693

[NFC][scudo] Add paramenters DCHECKs

Reviewed By: hctim

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

lld-coff: Simplify a few lambda uses after 7975dd033cb9

Add a range-based wrapper for std::unique(begin, end, binary_predicate)

[NFC][OMP] Fix 'unused' warning

[NFC][scudo] Avoid cast in test

[dsymutil] Emit an error when the Mach-O exceeds the 4GB limit.

The Mach-O object file format is limited to 4GB because its used of
32-bit offsets in the header. It is possible for dsymutil to (silently)
emit an invalid binary. Instead of having consumers deal with this, emit
an error instead.

[dsymutil] Use EXIT_SUCCESS and EXIT_FAILURE (NFC)

[dsymutil] Compute the output location once per input file (NFC)

Compute the location of the output file just once outside the loop over
the different architectures.

PR50456: Properly handle multiple escaped newlines in a '*/'.

[scudo] Add unmapTestOnly() to secondary.

When trying to track down a vaddr-poisoning bug, I found that that the
secondary cache isn't emptied on test teardown. We should probably do
that to make the tests hermetic. Otherwise, repeating the tests lots of
times using --gtest_repeat fails after the mmap vaddr space is
exhausted.

To repro:
$ ninja check-scudo_standalone # build
$ ./projects/compiler-rt/lib/scudo/standalone/tests/ScudoUnitTest-x86_64-Test \
--gtest_filter=ScudoSecondaryTest.*:-ScudoSecondaryTest.SecondaryCombinations \
--gtest_repeat=10000

Reviewed By: cryptoad

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

[mlir-opt] Don't enable `printOpOnDiagnostic` if it was explicitly disabled.

We are currently explicitly setting the flag solely based on the value of `-verify`, which ends up ignoring the situation where the user explicitly disabled this option from the command line.

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