This adds explanations and instructions on how to set up a dialect for
sharded op definitions to the MLIR documentation.

stack-info: PR: https://github.com/llvm/llvm-project/pull/89664, branch: users/Mogball/stack/3

This PR uses the new op sharding mechanism in tablegen to shard the test
dialect's op definitions. This breaks the definition of ops into
multiple source files, speeding up compile time of the test dialect
dramatically. This improves developer cycle times when iterating on the
test dialect.

stack-info: PR: https://github.com/llvm/llvm-project/pull/89628, branch: users/Mogball/stack/1

Adds an option to `mlir-tblgen -gen-op-defs` `op-shard-count=N` that divides the
op class definitions and op list into N segments, e.g.

```
// mlir-tblgen -gen-op-defs -op-shard-count=2

void FooDialect::initialize() {
  addOperations<
  >();
  addOperations<
  >();
}

```

When split across multiple source files, this can help significantly improve
dialect compile time for dialects with a large opset.

stack-info: PR: https://github.com/llvm/llvm-project/pull/89423, branch: users/mogball/pr_1

This PR massively reorganizes the Test dialect's source files. It moves
manually-written op hooks into `TestOpDefs.cpp`, moves format custom
directive parsers and printers into `TestFormatUtils`, adds missing
comment blocks, and moves around where generated source files are
included for types, attributes, enums, etc. into their own source file.

This will hopefully help navigate the test dialect source code, but also
speeds up compile time of the test dialect by putting generated source
files into separate compilation units.

This also sets up the test dialect to shard its op definitions, done in
the next PR.

This implements a RISCV specific version of the SHL_ADD node proposed in
https://github.com/llvm/llvm-project/pull/88791.

If that lands, the infrastructure from this patch should seamlessly
switch over the to generic DAG node. I'm posting this separately because
I've run out of useful multiply strength reduction work to do without
having a way to represent MUL X, 3/5/9 as a single instruction.

The majority of this change is moving two sets of patterns out of
tablgen and into the post-legalize combine. The major reason for this is
that I have an upcoming change which needs to reuse the expansion logic,
but it also helps common up some code between zba and the THeadBa
variants.

On the test changes, there's a couple major categories:
* We chose a different lowering for mul x, 25. The new lowering involves
one fewer register and the same critical path, so this seems like a win.
* The order of the two multiplies changes in (3,5,9)*(3,5,9) in some
cases. I don't believe this matters.
* I'm removing the one use restriction on the multiply. This restriction
doesn't really make sense to me, and the test changes appear positive.

When responding to review comments, `return {}` was accidentally replaced
by `std::nullptr` instead of `return std::nullptr`.

This reverts commit 8b2ba6a1.

The uild errors (see below) were likely due to the same issue PR #88074 fixed. Addressed by following that PR.

https://lab.llvm.org/buildbot/#/builders/165/builds/52789
https://lab.llvm.org/buildbot/#/builders/91/builds/25273

This also adds a few tests that were missing.

I made a small typo when writing a test for MathExtras.h, sorry!

The `column` field is mandatory in StackTraceResponse, otherwise the
debugger client may raise error (e.g. VSCode can't correctly open an
editor without the column field)

---------

Signed-off-by: Xu Jun <693788454@qq.com>

Emit a special leaf construct table in DirectiveEmitter.cpp, which will
allow both decomposition of a construct into leafs, and composition of
constituent constructs into a single compound construct (if possible).
The function `getLeafConstructs` is no longer auto-generated, but
implemented in OMP.cpp.

The table contains a row for each directive, and each row has the
following format
`dir_id, num_leafs, leaf1, leaf2, ..., leafN, -1, ...`
The rows are sorted lexicographically with respect to the leaf
constructs. This allows a binary search for the row corresponding to the
given list of leafs.

There is an auxiliary table that for each directive contains the index
of the row corresponding to that directive.

Looking up leaf constructs for a directive `dir_id` is of constant time,
and and consists of two lookups: `LeafTable[Auxiliary[dir_id]]`.
Finding a compound directive given the set of leafs is of time O(logn),
and is roughly represented by
`row = binary_search(LeafTable); return row[0]`.

The functions `getLeafConstructs` and `getCompoundConstruct` use these
lookup methods internally.

https://reviews.llvm.org/D47919 dumped RELR relocations as
`R_*_RELATIVE` and added --raw-relr (not in GNU) for testing purposes
(more readable than `llvm-readelf -x .relr.dyn`). The option is obsolete
after `llvm-readelf -r` output gets improved (#89162).

Since --raw-relr never seems to get more adoption. Let's remove it to
avoid some complexity.

Pull Request: https://github.com/llvm/llvm-project/pull/89426

Summary:
The move from `openmp` to `offload` did not preserve the per-target
runtime directory installation. This is important because this
per-target directory is always included first and is likely the de-facto
way to handle these going forward. Without this installation, old
installations of the library will be linked against first.

-O0 implies -mrelax-all as an assembler compile time optimization.
-mrelax-all allows the assembler to complete layout in 2 passes instead
of doing iterative branch relaxation.

Jump offsets larger than +/-1MiB require an indirect jump on RISC-V.
This can't be done by the assembler, so we use a branch relaxation MIR
pass and use register scavenging to find a free register.

The conditional branch offsets for RISC-V are also somewhat small so we
support MC layer branch relaxation to make life easier for assembly
programmers. This may also cover up bugs in our function size estimation
in MachineIR.

Enabling -mrelax-all causes the MC layer relaxation to agressively relax
branches. This increases code size and can create cases where we need an
indirect jump, but we can't create one. This leads to linker failures.

The easiest way to avoid this is to not default to -mrelax-all for -O0
and sacrifice the compile time optimization. That's what this patch
does.

Fixes #87127

Implement:
- pthread_rwlockattr_destroy
- pthread_rwlockattr_getpshared
- pthread_rwlockattr_init
- pthread_rwlockattr_setpshared

It would be helpful in future code reviews to document a policy with
regards to
where and when Assembler sources are appropriate. That way when
reviewers point
out infractions, they can point to this written policy, which may help
contributors understand that it's not solely the personal preferences of
individual reviewers but instead rather a previously agreed upon rule by
maintainers.

Link: https://github.com/llvm/llvm-project/pull/87837
Link: https://github.com/llvm/llvm-project/pull/88157
Link:
https://discourse.llvm.org/t/hand-written-in-assembly-in-libc-setjmp-longjmp/73249/12

MLIR uses zero-width integers, but also re-uses integer logic from LLVM
to avoid duplication. This creates issues when LLVM logic is used in
MLIR on integers which can be zero-width. In order to avoid
special-casing the bitwidth-related logic in MLIR, this PR adds support
for zero-width integers in LLVM's MathExtras (and consequently APInt).

While most of the logic in theory works the same way out of the box,
because bitshifting right by the entire bitwidth in C++ is undefined
behavior instead of being zero, some special cases had to be added.
Fortunately, it seems like the performance penalty is small. In x86,
this usually yields the addition of a predicated conditional move. I
checked that no branch is inserted in Arm too.

This happens to fix a crash in `arith.extsi` canonicalization in MLIR. I
think a follow-up PR to add tests for i0 in arith would be beneficial.

When building overlay mode with GCC in release mode, glibc's stdlib.h
contains
an extern inline declaration of bsearch. This breaks our use of the
gnu::alias
function attribute in LLVM_LIBC_FUNCTION with GCC because GCC checks
that the
aliasee is defined in the same TU (clang does not).

We're looking at also potentially updating our definition of
LLVM_LIBC_FUNCTION
from libc/src/__support/common.h. Upon testing, I was able to get
-Wnonnull-compare diagnostics from GCC in our definition of bsearch
because
glibc declares bsearch with the fugly nonnull function attribute.

There's more we can do here though to improve our implementation of
bsearch.
7.24.5.1 says:

    Pointer arguments on such a call shall still have valid values, as
    described in 7.1.4.

We could also use either function attributes or parameter attributes to
denote
these should not be null (for users/callers) and perhaps still check for
non-null explicitly under some yet to be discussed hardening
configurations in
the future.

Link: #60481
Link:
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-nonnull-function-attribute

This exposes _BitInt literal suffixes __wb and u__wb as an extension
in C++. There is a new Extension warning, and the tests are
essentially the same as the existing _BitInt literal tests for C but
with a few additional cases.

Fixes #85223

topperc pointed this out in review of
https://github.com/llvm/llvm-project/pull/88791, but I believe the
problem applies
here as well. Worth noting is that the code I introduced with this bug
was mostly copied from other targets - which
also have this bug.

The current code is so buggy: it can work for few cases. The problems
include:
1. ll/sc works on a whole word, while other parts other than we rmw are
dropped.
  2. The oprands are not well zero-extended for unsigned ops.
3. It doesn't work for big-endian, as the postion of subword differs
with little endian.

And in fact, we can set the return value correct in ll/sc scope, so we
can skip the sinkMBB.

Specifying checks using the literal style (|) in the clang-tidy config
file is currently supported but was not implemented for the
--verify-config options. This means that clang-tidy would work properly
but, using the --verify-config option would raise an error due to some
checks not being parsed properly.

Fixes #53737

This will remove the distinction between begin clauses and end clauses,
and process all of them together.

This patch:
- Adds SPIR-V backend's registered generator magic number to the emitted
binary. The magic number consists of the generator ID (43) and LLVM
major version.
- Adds SPIR-V version to the binary.
- Allows reading the expected (maximum supported) SPIR-V version from
the target triple.
- Uses VersionTuple for representing versions throughout the backend's
codebase.
- Registers v1.6 for spirv32 and spirv64 triple.

See more: https://github.com/KhronosGroup/SPIRV-Headers/commit/7d500c

Summary:
AddMemoryList() was returning the last error status returned by
ReadMemory(). So if an invalid memory region was read last, the function
would return an error.

Test Plan:
./bin/llvm-lit -sv
~/src/llvm-project/lldb/test/API/functionalities/process_save_core_minidump/TestProcessSaveCoreMinidump.py

Reviewers:
kevinfrei,clayborg 

Subscribers:

Tasks:

Tags:

[clang][CoverageMapping] do not emit a gap region when either end doesn't have valid source locations (#89564)

Fixes #86998

This adds a new RISCVExtension class that inherits from
SubtargetFeature. This contains the major/minor version and whether the
extension is experimental. The plan is to use this to generate the
tables for RISCVISAInfo.cpp.

The version numbers might not be accurate yet. If there are errors they
will be fixed before they are used for anything. It will be easier to
verify once the new tablegen backend is written to generate the
RISCVISAInfo.cpp table.

Currently `__is_trivially_equality_comparable` is documented to return
true if comparing the value representation is equivalent to calling the
comparison operator, which is not quite what the trait actually checks.
The traits actually checks that comparing the object representation is
equivalent, which means that there cannot be padding bytes in the type.

This PR fixes the build errors for one of the `clangd` unit tests bucket
similar to the following:

```
.../clang-tools-extra/clangd/unittests/FindTargetTests.cpp:430:29: error: passing no argument for the '...' parameter of a variadic macro is a C++20 extension [-Werror,-Wc++20-extensions]
  430 |   EXPECT_DECLS("AutoTypeLoc");
      |                             ^
.../clang-tools-extra/clangd/unittests/FindTargetTests.cpp:98:9: note: macro 'EXPECT_DECLS' defined here
   98 | #define EXPECT_DECLS(NodeType, ...)                                            \
      |         ^
```

This happens when using a build compiler with #84520. The fix is to
include commas to compensate for empty vararg macro arguments in a few
instances.

Use the new getPointerSize() function throughout the frame lowering class.

Make it part of -Wformat-pedantic.

Fixes #81647

Fix parsing of cuda_kernel: it missed a mlir::succeeded check and it was
not setting up the `types` and causing mismatch between values and types
of the grid/block (CUFKernelValues). @clementval

---------

Co-authored-by: Iman Hosseini <imanh@nvidia.com>
Co-authored-by: Valentin Clement (バレンタイン クレメン) <clementval@gmail.com>

As the goal of LLVM reduce is to simplify the input file, it should not
modify the debug info format - doing so by default would make it
impossible to reduce an error that only occurs in the old format, for
example (as briefly discussed at
https://github.com/llvm/llvm-project/pull/86275). This patch uses the
new "preserve debug info format" flag in llvm-reduce to prevent the
input from being subtly transformed by llvm-reduce itself; this has no
effect on any tools used for the interestingness check (i.e. if `opt` is
invoked, it will still convert the reduced input to the new format by
default), but simply ensures that the reduced file is strictly reduced
rather than modified.

In a nutshell, this moves our libomptarget code to populate the offload
subproject.

With this commit, users need to enable the new LLVM/Offload subproject
as a runtime in their cmake configuration.
No further changes are expected for downstream code.

Tests and other components still depend on OpenMP and have also not been
renamed. The results below are for a build in which OpenMP and Offload
are enabled runtimes. In addition to the pure `git mv`, we needed to
adjust some CMake files. Nothing is intended to change semantics.

```
ninja check-offload
```
Works with the X86 and AMDGPU offload tests

```
ninja check-openmp
```
Still works but doesn't build offload tests anymore.

```
ls install/lib
```
Shows all expected libraries, incl.
- `libomptarget.devicertl.a`
- `libomptarget-nvptx-sm_90.bc`
- `libomptarget.rtl.amdgpu.so` -> `libomptarget.rtl.amdgpu.so.18git`
- `libomptarget.so` -> `libomptarget.so.18git`

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



---------

Co-authored-by: Saiyedul Islam <Saiyedul.Islam@amd.com>

This addresses two problems observed in #89407 wrt user-defined
`static_assert` messages:

1. In `Expr::EvaluateCharRangeAsString`, we were calling `getExtValue()`
instead of `getZExtValue()`, which would assert if a negative or very
large number was returned from `size()`.
2. If the value could not be converted to `std::size_t`, attempting to
diagnose that would crash because `ext_cce_narrowing` was missing two
`%select` cases.

This fixes #89407.

- `clang/lib/CodeGen/CGBuiltin.cpp` - switch to using
`getLerpIntrinsic()` to abstract backend intrinsic
- `clang/lib/CodeGen/CGHLSLRuntime.h` - add `getLerpIntrinsic()` 
- `llvm/include/llvm/IR/IntrinsicsSPIRV.td` - add SPIRV intrinsic for
lerp
- `llvm/lib/Target/SPIRV/SPIRVInstructionSelector.cpp` - add mapping of
HLSL's lerp to GLSL's Fmix.

resolves #88940

Reverts llvm/llvm-project#89304

Some build bot failures - will fix and reland.

Example: https://lab.llvm.org/buildbot/#/builders/165/builds/52789