Renames `populateVectorTransferCollapseInnerMostContiguousDimsPatterns`
as `populateDropInnerMostUnitDimsXferOpPatterns` + updates the
corresponding comments.
This addresses a TODO and makes the difference between these two
`populate*` methods clearer:
* `populateDropUnitDimWithShapeCastPatterns`,
* `populateDropInnerMostUnitDimsXferOpPatterns`.
Support custom types (2/N): allow value-owning operations (e.g.
allocation ops) to bufferize custom tensors into custom buffers. This
requires BufferizableOpInterface::getBufferType() to return
BufferLikeType instead of BaseMemRefType.
Affected implementors of the interface are updated accordingly.
Relates to ee070d08163ac09842d9bf0c1315f311df39faf1.
This PR adds the `-Gis` option to clang-dxc, to instruct the behavior to
enable IEEE strict mode. The purpose is so that clang-dxc behaves as DXC
does when it takes the -Gis option.
Fixes https://github.com/llvm/llvm-project/issues/145589
This uses LIT substitutions in a response file that could contain spaces
in paths. This caused a failure on a build bot where the path to the
system Python executable was "C:\Program Files\Python310\python.exe", as
reported in #142757.
Add appropriate quoting to fix the issue.
In DXC, there is an option to enable all KHR extension. I would like to
extend the existing `-spirv-ext` backend commandline option to have the
same capability. It is like the special case for `all` execept it only
adds the `SPV_KHR_*` extensions.
Part of https://github.com/llvm/llvm-project/issues/137650.
This patch fixes the following error:
```
llvm/lib/Support/TextEncoding.cpp:274:11: error: cannot initialize a variable of type 'char *' with an rvalue of type 'const char *'
274 | char *Input = InputLength ? const_cast<char *>(Source.data()) : "";
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
This patch introduces a new custom type `!spirv.arm.tensor<>` to the
MLIR SPIR-V dialect to represent
`OpTypeTensorARM` as defined in the `SPV_ARM_tensors` extension.
The type models a shaped tensor with element type and optional shape,
and implements the
`ShapedType` interface to enable reuse of MLIR's existing shape-aware
infrastructure.
The type supports serialization to and from SPIR-V binary as
`OpTypeTensorARM`, and emits the
required capability (`TensorsARM`) and extension (`SPV_ARM_tensors`)
declarations automatically.
This addition lays the foundation for supporting structured tensor
values natively in SPIR-V and
will enable future support for operations defined in the
`SPV_ARM_tensors` extension, such as
`OpTensorReadARM`, `OpTensorWriteARM`, and `OpTensorQuerySizeARM`.
Reference: https://github.com/KhronosGroup/SPIRV-Registry/pull/342
---------
Signed-off-by: Davide Grohmann <davide.grohmann@arm.com>
Signed-off-by: Mohammadreza Ameri Mahabadian <mohammadreza.amerimahabadian@arm.com>
This patch fixes:
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:415:7:
error: label at end of compound statement is a C++23 extension
[-Werror,-Wc++23-extensions]
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:536:7:
error: label at end of compound statement is a C++23 extension
[-Werror,-Wc++23-extensions]
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:672:7:
error: label at end of compound statement is a C++23 extension
[-Werror,-Wc++23-extensions]
PR #141106 changed the debuginfo metdata to allow dynamic bit offsets
and sizes. This caused a crash in lld when using LTO.
The problem is that lazyLoadOneMetadata assumes that the metadata in
question can be cast to MDNode; but in the typical case where the offset
is a constant, this is not true.
This patch changes this spot to allow non-MDNodes through.
The included test case comes from the report in #141106.
Summary:
The allocator interface is supposed to have 16 byte alignment (to keep
it consistent with the CPU allocator. We could probably drop this to 8
if desires.) But this was not enforced because the number of bytes used
for the bitfield sometimes resulted in alignment of 8 instead of 16.
Explicitly align the number of bytes to be a multiple of 16 even if
unused.
This PR reworks https://github.com/llvm/llvm-project/pull/131803.
Instead of applying the optimization on transfer_read op, which is too
high level, it redirect the pre-existing pattern onto maskedload op.
This simplified the implementation of the lowering pattern. This also
allows moving the usage of the pass to a target dependent pipeline.
Signed-off-by: jerryyin <zhuoryin@amd.com>
While fixing bugs in the x86_64 LC_THREAD parser in ObjectFileMachO, I
noticed that the other LC_THREAD parsers are all less clear than they
should be.
To recap, a Mach-O LC_THREAD load command has a byte size for the entire
payload. Within the payload, there will be one or more register sets
provided. A register set starts with a UInt32 "flavor", the type of
register set defined in the system headers, and a UInt32 "count", the
number of UInt32 words of memory for this register set. After one
register set, there may be additional sets. A parser can skip an unknown
register set flavor by using the count field to get to the next register
set. When the total byte size of the LC_THREAD load command has been
parsed, it is completed.
This patch fixes the riscv/arm/arm64 LC_THREAD parsers to use the total
byte size as the exit condition, and to skip past unrecognized register
sets, instead of stopping parsing.
Instead of fixing the i386 corefile support, I removed it. The last
macOS that supported 32-bit Intel code was macOS 10.14 in 2018. I also
removed i386 KDP support, 32-bit intel kernel debugging hasn't been
supported for even longer than that.
It would be preferable to do these things separately, but I couldn't
bring myself to update the i386 LC_THREAD parser, and it required very
few changes to remove this support entirely.
Adds support for __sys Clang builtin for AArch64
__sys is a long existing MSVC intrinsic used to manage caches, tlbs, etc
by writing to system registers:
* It takes a macro-generated constant and uses it to form the AArch64 SYS instruction which is MSR with op0=1. The macro drops op0 and expects the implementation to hardcode it to 1 in the encoding.
* Volume use is in systems code (kernels, hypervisors, boot environments, firmware)
* Has an unused return value due to MSVC cut/paste error
Implementation:
* Clang builtin, sharing code with Read/WriteStatusReg
* Hardcodes the op0=1
* Explicitly returns 0
* Code-format change from clang-format
* Unittests included
* Not limited to MSVC-environment as its generally useful and neutral
The "XtensaMCExpr.h" used by XtensaELFObjectWriter was removed by
previous commit. And functionality from this file is now implemented in
"XtensaMCAsmInfo.h". So, fix this situation.
When targeting GFX950, disassembly of v_permlane16_swap_b32 and
v_permlane32_swap_b32 instructions produces errors when they use certain
vdst operand values, e.g., v_permlane16_swap_b32 v218, v219. This patch
fixes this problem.
Unknown intrinsics are functions that begin with `llvm.` but are not an
intrinsic that is recognized by LLVM. Add a comment before such
functions in LLVM IR assembly to indicate that they are unknown
intrinsics.
Fix#141753 .
This patch introduces a new check, that tries to decide if the
conjunction of all the values uniquely identify the accepted values by
the switch.
In Vulkan, the signedness of the accesses to images has to match the
signedness of the backing image.
See
https://docs.vulkan.org/spec/latest/chapters/textures.html#textures-input,
where it says the behaviour is undefined if
> the signedness of any read or sample operation does not match the
signedness of the image’s format.
Users who define say an `RWBuffer<int>` will create a Vulkan image with
a signed integer format. So the HLSL that is generated must match that
expecation.
The solution we use is to generate a `spirv.SignedImage` target type for
signed integer instead of `spirv.Image`. The two types are otherwise the
same.
The backend will add the `signExtend` image operand to access to the
image to ensure the image is access as a signed image.
Fixes#144580
This replicates clang's implementation. Basically:
- A private copy of the reduction variable is created, initialized to
the reduction neutral value (using regions from the reduction
declaration op).
- The body of the loop is lowered as usual, with accesses to the
reduction variable mapped to the private copy.
- After the loop, we inline the reduction region from the declaration op
to combine the privatized variable into the original variable.
- As usual with the SIMD construct, attributes are added to encourage
vectorization of the loop and to assert that memory accesses in the loop
don't alias across iterations.
I have verified that simple scalar examples do vectorize at -O3 and the
tests I could find in the Fujitsu test suite produce correct results. I
tested on top of #146097 and this seemed to work for composite
constructs as well.
Fixes#144290
Some intrinsics like llvm.abs or llvm.powi have a scalar argument even
when the overloaded type is a vector.
This patch handles these in scalarizeOpOrCmp to allow scalarizing them.
In the test the leftover vector powi isn't folded away to poison, this
should be fixed in a separate patch.
This was removed in 99cdc26c94 when the LLVM monorepo Buildkite setup
was removed. Libc++ previously relied on the LLVM monorepo pipeline to
trigger its own pipeline when needed. Since there is no LLVM monorepo
pipeline anymore, we must trigger the libc++ Buildkite pipeline on every
pull request and use this script to determine which jobs to actually
start based on the files that are touched by the PR.
This PR adds the `mlir-translate` dependency to CIR.
The following test was failing when running `ninja check-clang-cir`:
```
CIR/Lowering/stack-save-restore.cir
line 2: mlir-translate: command not found
```
The failure occurred because `mlir-translate` was not being built as
part of the CIR test dependencies. This PR ensures that the target is
properly built so the test can run successfully.
Summary:
This didn't use the built-in 'CommaJoined' feature for arguments and
parsed out the strings manually. This patch simplifies this by just
using the present functionality.
Instead of emitting globals in the program/default address space, emit
them in the global address space. This also requires changes how address
of code-gen is handled, we need to cast to the default address space to
prevent code-gen issues.
This patch introduces support for Integrated Distributed ThinLTO (DTLTO)
in ELF LLD.
DTLTO enables the distribution of ThinLTO backend compilations via
external distribution systems, such as Incredibuild, during the
traditional link step: https://llvm.org/docs/DTLTO.html.
It is expected that users will invoke DTLTO through the compiler driver
(e.g., Clang) rather than calling LLD directly. A Clang-side interface
for DTLTO will be added in a follow-up patch.
Note: Bitcode members of archives (thin or non-thin) are not currently
supported. This will be addressed in a future change. As a consequence
of this lack of support, this patch is not sufficient to allow for
self-hosting an LLVM build with DTLTO. Theoretically,
--start-lib/--end-lib could be used instead of archives in a self-host
build. However, it's unclear how --start-lib/--end-lib can be easily
used with the LLVM build system.
Testing:
- ELF LLD `lit` test coverage has been added, using a mock distributor
to avoid requiring Clang.
- Cross-project `lit` tests cover integration with Clang.
For the design discussion of the DTLTO feature, see: #126654.
The plan is to move all STL formatter API tests into a single directory.
The `std::deque` test is currently the only test that is duplicated
between the `libcxx` and `generic` directories. This patch moves the
libcxx deque tests into `generic` (moving over any functionality that
wasn't tested in the `generic` tests, mainly formatting
pointers/references to `std::deque`).
