After frontend changes in the following commit:
"BPF: preserve btf_decl_tag for parameters of extern functions"
same mechanics could be used to get the list of function parameters
and associated btf_decl_tag entries for both extern and non-extern
functions.

This commit extracts this mechanics as a separate auxiliary function
BTFDebug::processDISubprogram(). The function is called for both
extern and non-extern functions in order to generated corresponding
BTF_DECL_TAG records.

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

This patch fixes the inaccurate decoding of the offset operand of
the RCALL & RJMP instructions.

Reviewed By: aykevl, MaskRay

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

SPIRVModuleAnalysis collects module and external function registers
(usually result of OpFunction) for use when emitting OpFunctionCall.
This patch makes the mapping between the functions and registers using
pointers (instead of name strings) to ensure anonymous functions and
calls can be resolved properly.

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

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

Generate DILocalVariable entries for parameters of extern functions,
the "annotations" field of DILocalVariable is used to link
"btf_decl_tag" annotation with the parameter.

Do this only for BPF backend as there are no other users for this
information. Final DWARF is valid as "Appendix A" is very much lax in
what is allowed as attributes for "DW_TAG_formal_parameter":

    DWARF does not in general require that a given debugging information
    entry contain a particular attribute or set of attributes. Instead,
    a DWARF producer is free to generate any, all, or none of the
    attributes ... other attributes ... may also appear in a given
    debugging information entry.

DWARF Debugging Information Format Version 5,
Appendix A: Attributes by Tag Value (Informative)
Page 251, Line 3.

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

Adds a utility method llvm::Triple::isBPF() aggregating Triple::bpfel
and Triple::bpfeb architectures. Similar to other predicates in this class.

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

This patch also fixes incorrect function declarations in test cases
and remove -disable-verify from the test case.

Fix https://github.com/llvm/llvm-project/issues/59839

... from d65e66ab.

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

Summary:
Don't check the flag this way, it leads to unused variables. Fix.

Some specific operands in specific instructions should be treated
as variables/symbols/labels, other than registers.

This patch fixes those ambiguous cases, such as "lds r25, r24",
which means loading the value inside symbol 'r24' into register 'r25'.

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

Reviewed by: aykevl

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

The device library uses this as a struct with a pointer sized integer
and 2 ints.

Invert the sense of the attribute and let the attributor figure this
out like everything else. If needed we can have the not-OpenCL
languages set amdgpu-no-default-queue and amdgpu-no-completion-action
up front so they never have to pay the cost.

There are also so many of these now, the offset use API should
probably consider all of them at once. Maybe they should merge into
one attribute with used fields. Having separate functions for each
field in AMDGPUBaseInfo is also not the greatest API (might as well
fix this when the patch to get the object version from the module
lands).

This was looking for a specific constant cast of the function, when
the type doesn't matter. Doesn't bother trying to handle typed
pointers, it will just assert.

Things probably don't work completely correctly if the block kernel
address is captured somewhere else, but that wouldn't work before
either. The uses should really be loads out of the handle, and the
handle initializer should contain the kernel address.

This demonstrates the pass is broken with them, the follow up change
will fix it.

Summary:
This option was spelled wrong and caused errors if used in combination
with the linking job. Fix it.

JIT support for OpenMP offloading was introduced in D139287. This patch
adds a simple flag that enables this mode. It simply requires enabling
`-foffload-lto` mode and `--embed-bitcode` in the linker wrapper. This
option implies LTO if it is not enabled.

Reviewed By: jdoerfert

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

Fix compiler build reported in https://lab.llvm.org/buildbot#builders/243/builds/218

The new mask represents the order, not the mask itself. At first, need
to treat as the order, convert to mask and only after that reorder
gathered scalars to build correct clustered order.

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

Also, skip installing startup objects for baremetal targets for now.

Reviewed By: michaelrj

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

Add a folder for LogicalNotEqual when rhs is false. This pattern shows
up after lowering to SPIRV.

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

Following support from the previous patches in this stack being added for
variadic DBG_INSTR_REFs to exist, this patch modifies LiveDebugValues to
handle those instructions. Support already exists for DBG_VALUE_LISTs, which
covers most of the work needed to handle these instructions; this patch only
modifies the transferDebugInstrRef function to correctly track them.

Reviewed By: jmorse

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

This diff completes switching Tosa to DenseArrayAttr.

Test plan: ninja check-mlir check-all

Differential revision: https://reviews.llvm.org/D141111

The original patch does include a `new` statement without a matching
`delete`, causing Sanitizer warnings in
https://lab.llvm.org/buildbot/#/builders/5/builds/30522/steps/13/logs/stdio.

This commit is a fix to it.

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

Fix "runtime runtime error" -> "runtime error"

Reviewed By: MaskRay

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

Attempt to fix test failures on big endian bots. This pass definitely
needs more test coverage.

Test various inputs passed to %s.

Reviewed By: mravishankar

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

[Support] On Windows 11 and Windows Server 2022, fix an affinity mask issue on large core count machines

Before Windows 11 and Windows Server 2022, only one 'processor group' is assigned by default to a starting process, then the program is responsible for dispatching its own threads on more 'processor groups'. That is what 8404aeb5 was doing, allowing LLVM tools to automatically use all hardware threads in the machine.

After Windows 11 and Windows Server 2022, the OS takes care of that. This has an adverse effect reported in #56618 which is that using `GetProcessAffinityMask()` API in some edge cases seems buggy now. That API is used to detect if an affinity mask was set, and adjust accordingly the available threads for a ThreadPool.

With this patch, on one hand, we let the OS dispatch threads on all 'processor groups', but only for Windows 11 & Windows Server 2022 and after. We retain the old behavior for older OS versions. On the other hand, a workaround was added to mitigate the `GetProcessAffinityMask()` issue described above (see Threading.inc, L226).

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

The generator expression previously used to enable exceptions would not work since the compiler id of clang-cl is Clang, even if used via clang-cl.

The patch fixes that by replacing the generator expression with simple logic, setting the right compiler flags for all MSVC like compilers (including clang-cl) and all GCC like compilers.

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

Before we always used DW_RLE_startx_length. This is not very efficient and leads
to bigger .debug_addr section. Changed it to use
DW_RLE_base_addressx/DW_RLE_offset_pair.

clang-16 build in debug mode
llvm-bolt ran on it with --update-debug-sections
| section | before | after | diff | % decrease |
| .debug_rnglists | 32732292 | 31986051 | -746241 | 2.3% |
| .debug_addr | 14415808 | 14184128 |  -231680 | 1.6% |

Reviewed By: maksfb

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

Revert "[Fix][-Wunsafe-buffer-usage] Add a new `forEachDescendant` matcher that skips callable declarations"

This reverts commit 6d140b95.

This commit may causes `test/SemaCXX/warn-unsafe-buffer-usage.cpp` failure.

The original patch does include a `new` statement without a matching
`delete`, causing Sanitizer warnings in
https://lab.llvm.org/buildbot/#/builders/5/builds/30522/steps/13/logs/stdio.

This commit is a fix to it.

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

As of several months ago, both ArithToLLVM and ArithToSPIRV have
native support for integer min and max operations. Since these are all
the targets available in MLIR core, the need to "expand" arith.minui,
arith.minsi, arith,maxsi, and arith.manxui to more primitive
operations is to longer present.

Therefore, the expanding of integer min and max operations in Arith,
while correct, is likely to lead to performance loss by way of
misoptimization further down the line, and is no longer needed for
anyone's correctness.

This change may break downstream tests, but will not affect the
semantics of MLIR programs.

arith.minf and arith.maxf have a lot of underlying complexity due to
the many different possible NaN and signed zero semantics available on
various platforms, and so removing their expansion is left to a future
commit.

Reviewed By: ThomasRaoux, Mogball

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