Close https://github.com/llvm/llvm-project/issues/62943.

The root cause for the issue is that we think the associated constraints
from the 'same' declaration in different module units are different
incorrectly. Since the constraints doesn't know anything about decls and
modules, we should fix the problem by getting the associated constraints
from the exactly the same declarations from different modules.

This adds a new command that will show all the information lldb
knows about a register.
```
(lldb) register info s0
       Name: s0
       Size: 4 bytes (32 bits)
Invalidates: v0, d0
  Read from: v0
    In sets: Floating Point Registers (index 1)
```

Currently it only allows a single register, and we get the
information from the RegisterInfo structure.

For those of us who know the architecture well, this information
is all pretty obvious. For those who don't, it's nice to have it
at a glance without leaving the debugger.

I hope to have more in depth information to show here in the future,
which will be of wider use.

Reviewed By: jasonmolenda

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

This reverts commit 1b9b78fd.

There are spurious test failures on the ml-* bots and some of the ARM
builders are complaining about shm_open being missing. Pulling this
commit so that I can investigate after I sleep.

This is intended to behave like GCC's `-mcmodel=extreme`.

Technically the true GCC equivalent would be `-mcmodel=large` which is
not yet implemented there, and we probably do not want to take the
"Large" name until things settle in GCC side, but:

* LLVM does not have a `CodeModel::Extreme`, and it seems too early to
  have such a variant added just for enabling LoongArch; and
* `CodeModel::Small` is already being used for GCC `-mcmodel=normal`
  which is already a case of divergent naming.

Regarding the codegen, loads/stores immediately after a PC-relative
large address load (that ends with something like `add.d $addr, $addr,
$tmp`) should get merged with the addition into corresponding `ldx/stx`
ops, but is currently not done. This is because pseudo-instructions are
expanded after instruction selection, and is best fixed with a separate
change.

Reviewed By: SixWeining

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

- Correctly handle OpNum == 0 (auto select operand)
- Implement MCExpr overload

Reviewed By: rafauler

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

Reviewed By: rafauler

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

Reviewed By: rafauler

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

This patch introduces the SubprocessMemory class to llvm-exegesis. This
class contains several utilities that are needed for managing memory to
set up an execution environment for memory annotations.

Reviewed By: courbet

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

This avoids bazel builds failing after commit bba2b656 because libmlir_test_spirv_cpu_runner_c_wrappers.so registers the same runner functions twice.

More precisely, this problem only shows up internally at Google because the bazel build does not have that target.

Either way though, it's better to IWYU.

This patch introduces the subprocess executor mode. Currently, this new
mode doesn't do anything fancy, just executing the same code that the
inprocess executor would do, but within a subprocess. This sets up the
ability to add in many more memory-related features in the future.

This patch adds a pass to generate `cm.mvsa01` & `cm.mva01s`.

RISCVMoveOptimizer.cpp which combines two mv inst into one cm.mva01s or cm.mva01s.

Reviewed By: craig.topper

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

Add test cases for vectorizing linalg.matmul and linalg.copy on tensors.

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

Support tiling of ops with memref semantics.

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

This change adds basic support for baremetal riscv32 configuration.

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

We already had an error for Zcmt though it appears to be untested
Add similar one for Zcmp along with tests for both.

Factor the code to share the strings as much as possible.

Reviewed By: VincentWu

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

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

Minor cleanup to take full advantage of OpFoldResult.

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

bufferization.to_memref ops are allowed in One-Shot Bufferize, but they are treated conservatively: in the absence of a memref analysis, we have to assume that the result buffer is read and written.

Note: to_memref cannot introduce any future aliases that would have to be considered during One-Shot Bufferize, because only to_tensor ops with the `restrict` attribute are supported. Such tensors are guaranteed to not alias with any other buffer after bufferization.

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

Reviewed By: pengfei

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

This change has a few additional effects:
- Abstract classes are now formattable.
- Volatile objects are no longer formattable.

Implements
- LWG3631 basic_format_arg(T&&) should use remove_cvref_t<T> throughout
- LWG3925 Concept formattable's definition is incorrect

Reviewed By: #libc, ldionne

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

As mentioned by commit c5d38924 (Apr 2020),
PC-relative entries avoid dynamic relocations and can therefore make the
section read-only.

This is similar to D78082 and D78590. We cannot commit to support
compiler/runtime built at different versions, so just don't play with versions.

For Mach-O support (incomplete yet), we use non-temporary `lxray_fn_idx[0-9]+`
symbols. Label differences are represented as a pair of UNSIGNED and SUBTRACTOR
relocations. The SUBTRACTOR external relocation requires r_extern==1 (needs to
reference a symbol table entry) which can be satisfied by `lxray_fn_idx[0-9]+`.
A `lxray_fn_idx[0-9]+` symbol also serves as the atom for this dead-strippable
section (follow-up to commit b9a134aa).

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

Before this change, a separate static method named cleanup was used to
cleanup the file. Instead, now the close method cleans up the full file
object using the platform's close function.

Reviewed By: lntue

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

The code at the beginning of the loop body and after the loop are
identifical. Move it to the end of the loop body by making a few
adjustments.

The value "true" and "false" are treated specially and other values are treated as integers.

Reviewed By: arsenm

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

The test requires that LLVM integreated assembler generates
SUBTRACTOR/UNSIGNED relocations for `.long _minuend_1 - _subtrahend_1`.
This currently works by luck because:

* `_minuend_1` and `_subtrahend_1` are in different fragments (separated by a MCFillFragment)
* and the result is known to be negative at parsing time.

D153096 will change the assembler to fold `.long _minuend_1 - _subtrahend_1` to
a constant, giving ld -order_file no chance to change the result.

To fix the test, move the referenced labels after the label differences to block
constant folding.

Note: you may think the model is somewhat broken and it is. The
.subsections_via_symbols mechanism does not block such constant folding. In
reality SUBTRACTOR/UNSIGNED is for references to another section, which does not
have the problem.

Reviewed By: #lld-macho, smeenai

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

Codegen can handle XRay for AArch64, tell the driver to allow it.

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

Handle PT_GNU_RELRO segment in accordance with Linux Standard Base spec
chapter 12:

> PT_GNU_RELRO
> The array element specifies the location and size of a segment which may
> be made *read-only* after relocations have been processed.

Perform a readelf-style mapping check between this segment and sections,
set `IsRelro` section attribute.

Reviewed By: #bolt, maksfb

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

Codegen OS-agnostic for ELF and the runtime is mostly OS-agnostic. It
seems unnecessary to make restriction.

While here, rewrite test/Driver/XRay/xray-instrument*.c to be more conventional:
specify --target= explicitly instead of relying on the configured default target
(which needs `REQUIRES:`).

I am not sure enumerating every supported architecture is useful, so we just test a few.

This reverts commit 0d4ef4ff.

This was causing build failures on certain platforms when built with
-Werror due to unused variable warnings in addition to causing build
failures on Linux systems with older kernel versions as kernels prior to
v5.15 don't support sys_pidfd_getpid. Reverting as I need to setup a
system to properly test the rest of the patches in this series.

Also reverts 8c6668fa which fixed the
first issue so that the patch can actually be reverted.

/data/llvm-project/llvm/tools/llvm-exegesis/lib/BenchmarkRunner.cpp:275:9: error: unused variable 'ParentPIDFD' [-Werror,-Wunused-variable]
    int ParentPIDFD = syscall(SYS_pidfd_open, ParentPID, 0);
        ^
1 error generated.

This class has been causing me no end of grief for a long time, and the way it is used by mlir-tblgen is technically an ODR violation in certain situations.

Due to the way that the build is layered, it is important that the MLIR tablegen libraries only depend on the LLVM tablegen libraries, not on anything else (like MLIRSupport). It has to be this way because these libraries/binaries are special and must pre-exist the full shared libraries. Therefore, the dependency chain must be clean (and static).

At some point, someone pulled out a separate build target for just IndendedOstream in an attempt to satisfy the constraint. But because it is weird in different ways, this target was never installed properly as part of distributions, etc -- this causes problems for downstreams seeking to build a tblggen binary that doesn't itself have ODR/shared library problems.

I was attempting to fix the distribution stuff but just opted to collapse this into a header-only library and not try to solve this with build layering. I think this is the safest and the least bad thing for such a dep. This also makes for a clean comment that actually explains the constraint (which I was having trouble verbalizing with the weird subset dependency).

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

This patch introduces the subprocess executor mode. Currently, this new
mode doesn't do anything fancy, just executing the same code that the
inprocess executor would do, but within a subprocess. This sets up the
ability to add in many more memory-related features in the future.

Reviewed By: courbet

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

This avoids a regression when SignBitMustBeZero is moved to computeKnownFPClass.

This patch gives the ability to assign performance counters within
llvm-exegesis to a specific process by passing its PID. This is needed
later on for implementing a subprocess executor. Defaults to zero, the
current process, for the InProcessFunctionExecutorImpl.

Reviewed By: courbet

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