Buildkite does not allow user perf monitoring and fails: https://buildkite.com/llvm-project/upstream-bazel/builds/49579.

```
[ RUN      ] PerfHelperTest.FunctionalTest
Unable to open event. ERRNO: Permission denied. Make sure your kernel allows user space perf monitoring.
You may want to try:
$ sudo sh -c 'echo -1 > /proc/sys/kernel/perf_event_paranoid'
llvm_exegesis_tests: external/llvm-project/llvm/tools/llvm-exegesis/lib/PerfHelper.cpp:111: llvm::exegesis::pfm::Counter::Counter(llvm::exegesis::pfm::PerfEvent &&): Assertion `FileDescriptor != -1 && "Unable to open event"' failed.
```

Reviewed By: aartbik

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

We used to have `pfm` built into exegesis, although since it's an external dependency we marked it as a manual target. Because of this we didn't have buildbot coverage and so we removed it in D134510 after we had a few breakages that weren't caught. This adds it back, but with three possible states similar to the story with `mpfr`, i.e. it can either be disabled, built from external sources (git/make), or use whatever `-lpfm` is installed on the system.

This change is modeled after D119547. Like that patch, the default is off (matching the status quo), but unlike that patch we don't enable it for CI because IIRC we don't have the package installed there, and building from source might be expensive. We could  enable it later either after installing it on buildbot machines or by measuring build cost and deeming it OK.

Reviewed By: GMNGeoffrey

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

As discussed in issue #59279, we want fneg/fabs to conform to the
IEEE-754 spec for signbit operations - quoting from section 5.5.1
of IEEE-754-2008:
"negate(x) copies a floating-point operand x to a destination in
the same format, reversing the sign bit"
"abs(x) copies a floating-point operand x to a destination in the
same format, setting the sign bit to 0 (positive)"
"The operations treat floating-point numbers and NaNs alike."

So we gate this transform with "nnan" in addition to "nsz":
(X > 0.0) ? X : -X --> fabs(X)

Without that restriction, we could have for example:
(+NaN > 0.0) ? +NaN : -NaN --> -NaN
(because an ordered compare with NaN is always false)
That would be different than fabs(+NaN) --> +NaN.

More fabs/fneg patterns demonstrated here:
https://godbolt.org/z/h8ecc659d
(without any FMF, these are correct independently of this patch -
no fabs should be created)

The code change is a one-liner, but we have lots of tests diffs
because there are many variations of the basic pattern.

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

We can use ShuffleInstructionBuilder now for shrinking shuffle emission.
It allows to remove extra shuffle from the emitted code and reuse
original vector.

Part of D110978

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

It's a strictly-developer feature, which is useless most of the time.

Fixes https://github.com/llvm/llvm-project/issues/59082

Reviewed By: RKSimon, gchatelet

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

Existing version ignores symbols declared in an inline namespace `ns`
when removing `using namespace ns`

Reviewed By: tom-anders

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

[mlir] NFC: work around gcc-aarch64 v8.3 compilation issue in getRegionBranchSuccessorOperands implementation.

ISD::INSERT_VECTOR_ELT is already set above.

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

"__cmpccxadd_epi*" -> "_cmpccxadd_epi*"
This is to align with other intrinsics to follow single leading "_" style. Gcc
and intrinsic guide website will also apply this change.

Reviewed By: LuoYuanke, skan

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

Fix typos `riscv-toolchai-convention` --> `riscv-toolchain-convention`

Reviewed By: craig.topper

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

This option helps some MMA related cases to reduce unnecessary copies.

Reviewed By: shchenz

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

Previously this was incorrectly assigning py::none to where function was
expected which resulted in failure if one used a non-attribute for
attribute without registered builder.

Commit f27c4903 ("MC: Add .data. and .rodata. prefixes to MCContext
section classification") added a test assuming bpf target. But it
is possible bpf target is not configured in the clang build.
Let us add explicit bpf-target requirement for the test
so the test can be ingored properly for clang build without enabling
bpf target.

Reviewed By: aartbik

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

This patch adds the basic JIT support for OpenMP. Currently it only works on Nvidia GPUs.

The support for AMDGPU can be extended easily by just implementing three interface functions. However, the infrastructure requires a small extra extension (add a pre process hook) to support portability for AMDGPU because the AMDGPU backend reads target features of functions. https://github.com/shiltian/llvm-project/commit/02bc7effccc6ff2f5ab3fe5218336094c0485766#diff-321c2038035972ad4994ff9d85b29950ba72c08a79891db5048b8f5d46915314R432 shows how it roughly works.

As for the test, even though I added the corresponding code in CMake files, the test still cannot be triggered because some code is missing in the new plugin CMake file, which has nothing to do with this patch. It will be fixed later.

In order to enable JIT mode, when compiling, `-foffload-lto` is needed, and when linking, `-foffload-lto -Wl,--embed-bitcode` is needed. That implies that, LTO is required to enable JIT mode.

Reviewed By: jdoerfert

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

This reverts commit 58906e49 because it breaks AMD's buildbot.

The preheader was named explicitly in 256c6b0b
which makes setting the name in prior commit 95b2aa51
unnecessary.

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

This is a code optimization patch that does not include feature additions
or deletions.

Reviewed By: SixWeining

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

last bits and pieces of the environment refactoring

Reviewed By: Peiming

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

The current code did not properly handled duplicated FoldCacheUser ID
entries when overwriting an existing entry in the FoldCache.

This triggered verification failures reported by @uabelho and #59721.

The patch fixes that by removing stale IDs when overwriting an existing
entry in the cache.

Fixes #59721.

This patch adds the basic JIT support for OpenMP. Currently it only works on Nvidia GPUs.

The support for AMDGPU can be extended easily by just implementing three interface functions. However, the infrastructure requires a small extra extension (add a pre process hook) to support portability for AMDGPU because the AMDGPU backend reads target features of functions. https://github.com/shiltian/llvm-project/commit/02bc7effccc6ff2f5ab3fe5218336094c0485766#diff-321c2038035972ad4994ff9d85b29950ba72c08a79891db5048b8f5d46915314R432 shows how it roughly works.

As for the test, even though I added the corresponding code in CMake files, the test still cannot be triggered because some code is missing in the new plugin CMake file, which has nothing to do with this patch. It will be fixed later.

In order to enable JIT mode, when compiling, `-foffload-lto` is needed, and when linking, `-foffload-lto -Wl,--embed-bitcode` is needed. That implies that, LTO is required to enable JIT mode.

Reviewed By: jdoerfert

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

Commit 463da422 ("MC: make section classification a bit more
thorough") changed MCContext::getELFSection section classification logic
to default to SectionKind::getText (previously default was
SectionKind::getReadOnly) and added some matching based on section name
to determine internal section classification.

The BPF runtime implements global variables using 'BPF map'
datastructures, specifically the arraymap BPF map type. Global variables
in a section are placed in a single arraymap value at predictable byte
offsets. Variables in different sections are placed in separate
arraymaps, so in this example:

  #define SEC(name) __attribute__((section(name)))
  SEC(".data.A") u32 one;
  SEC(".data.A") u32 two;
  SEC(".data.B") u32 three;
  SEC(".data.B") u32 four;

variables one and two would correspond to some byte offsets (probably 0
and 4) in one arraymap, while three and four would be in a separate
arraymap. Variables of a bpf_spin_lock type are considered to protect
next-generation BPF datastructure types in the same arraymap value and
there can only be a single bpf_spin_lock variable per arraymap value -
and thus per section.

As a result it's necessary to keep bpf_spin_locks and the datastructures
they guard in separate data sections. Before the aforementioned commit,
a section whose name starts with ".data." - like ".data.A" - would be
classified as SectionKind::getReadOnly, whereas after it is
SectionKind::getText. If 4-byte padding is required in such a section due to
alignment of some symbol within it, classification of the section as
SectionKind::getText will result in compilation of those variables to
BPF backend failing with an error like "unable to write nop sequence of
4 bytes". This is due to nop instruction emitted in
BPFAsmBackend::writeNopData being 8 bytes, so the function fails since
it cannot emit a 4-byte nop instruction.

Let's follow the pattern of matching section names starting with ".bss."
and ".tbss." prefixes resulting in proper classification of the section
as data by adding similar matches for ".data." and ".rodata." prefixes.
This will bring padding behavior for these sections back to what it was
before that commit and fix the crash.

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

Test case for issue reported by @uabelho and #59721

This relands commits e43924a7,
a43f3614,
bf94eac6 with MSan buildbot
https://lab.llvm.org/buildbot/#/builders/5/builds/30139
use-of-uninitialized-value errors fixed.

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

Reviewed By: aartbik

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

Reviewed By: Peiming

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

Merging regions can enable new sinking opportunities (e.g. if users of a
scalar value are moved from different VPBBs into the same VPBB). Sinking
in turn can also enable new merging opportunities (e.g. if a recipe
between to merge-able regions is moved.

To enable more sinking opportunities, repeat sinking & merging if
regions could be merged.

Also fix mergeReplicateRegions to return the correct Changed status.

Reviewed By: Ayal

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

Reviewed By: eopXD

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

The movprfx is a vector copy, so it doesn't access memory. Set the
value of hasSideEffects 0 to avoid return true for the hasUnmodeledSideEffects(),
which will block the machine scheduler which load/store instructions.

Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D140680

Fix incorrect markdown generated by mlir-tblgen for an InterfaceMethod
that includes a body.  Previously, this would cause the next method to
show up on the same line and produce incorrect markdown.  Newlines would
only be added if the method did _not_ provide a body.  E.g., previously
this was generating markdown like:

    some function comment#### `next method`

This change makes this generate as:

    some function comment

    #### `next method`

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>

Reviewed By: rriddle

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

If we go through the generic EmitGEPOffset code, the resulting
expression can be (and is) reduced in the same way this code did
manually. There are no changes in lit tests or llvm-test-suite.

This fold predates the time where we started adding nsw to the adds
created by EmitGEPOffset, so it was likely needed back then.

This might not actually be NFC due to worklist order changes etc.

Slightly adjust the test so it uses non-zero GEP indices, otherwise
these would get folded away with opaque pointers.