This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes#62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
The generic implementation is umin(TC, VF * vscale).
Lowering to vsetvli for RISC-V will come in a future patch.
This patch is a pre-requisite to be able to CodeGen vectorized code from
D99750.
Reviewed By: reames, frasercrmck
Differential Revision: https://reviews.llvm.org/D149916
At the moment, dsymutil drops all remarks without debug location.
There are many cases where debug location may be missing for remarks,
mostly due LLVM not preserving debug locations. When using bitstream
remarks for statistical analysis, those missed remarks mean we get an
incomplete picture.
The patch flips the default to keeping all remarks and leaving it to
tools that display remarks to filter out remarks without debug locations
as needed.
The new --remarks-drop-without-debug flag can be used to drop remarks
without debug locations, i.e. restore the previous behavior.
Reviewed By: thegameg
Differential Revision: https://reviews.llvm.org/D151089
In D148197, we have made `defvar` statement able to refer to class
template arguments. However, the priority of class/multiclass
template argument is higher than variables defined by `defvar`, which
is a little counterintuitive.
In this patch, we unify the priority of variables. Each pair of
braces introduces a new scope, which may contain some additional
variables like template arguments, loop iterators, etc. We can
define local variables inside this scope via `defvar` and these
variables are of higher priority than additional variables. This
means that `defvar` will shadow additional variables with the same
name. The scope can be nested, and we use the innermost variable.
This make variables defined by `defvar` prior to class/multiclass
template arguments, loop iterators, etc. The shadow rules now are:
* `V` in a record body shadows a global `V`.
* `V` in a record body shadows template argument `V`.
* `V` in template arguments shadows a global `V`.
* `V` in a `foreach` statement list shadows any `V` in surrounding record or global scopes.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D149016
getModuleMatchQuality was removed by:
commit c3719c36e61f6ac28fc1e12587131bcae6581671
Author: Daniel Dunbar <daniel@zuster.org>
Date: Sun Aug 2 23:37:13 2009 +0000
The Hexagon port was later added with getModuleMatchQuality by:
commit 1213a7a57fdcb6c875b3f79103fc96d3e9d30b40
Author: Tony Linthicum <tlinth@codeaurora.org>
Date: Mon Dec 12 21:14:40 2011 +0000
While we are at it, this patch removes a reference to
getModuleMatchQuality in the documentation.
This patch-set aims to simplify the existing RVV segment load/store
intrinsics to use a type that represents a tuple of vectors instead.
To achieve this, first we need to relax the current limitation for an
aggregate type to be a target of load/store/alloca when the aggregate
type contains homogeneous scalable vector types. Then to adjust the
prolog of an LLVM function during lowering to clang. Finally we
re-define the RVV segment load/store intrinsics to use the tuple types.
The pull request under the RVV intrinsic specification is
riscv-non-isa/rvv-intrinsic-doc#198
---
This is the 1st patch of the patch-set. This patch is originated from
D98169.
This patch allows aggregate type (StructType) that contains homogeneous
scalable vector types to be a target of load/store/alloca. The RFC of
this patch was posted in LLVM Discourse.
https://discourse.llvm.org/t/rfc-ir-permit-load-store-alloca-for-struct-of-the-same-scalable-vector-type/69527
The main changes in this patch are:
Extend `StructLayout::StructSize` from `uint64_t` to `TypeSize` to
accommodate an expression of scalable size.
Allow `StructType:isSized` to also return true for homogeneous
scalable vector types.
Let `Type::isScalableTy` return true when `Type` is `StructType`
and contains scalable vectors
Extra description is added in the LLVM Language Reference Manual on the
relaxation of this patch.
Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Co-Authored-by: eop Chen <eop.chen@sifive.com>
Reviewed By: craig.topper, nikic
Differential Revision: https://reviews.llvm.org/D146872
Provides MC layer support for Zvfbfwma: vector BF16 widening mul-add.
As currently specified, Zvfbfwma does not appear to have a dependency on
Zvfbfmin or Zfbfmin.
Differential Revision: https://reviews.llvm.org/D147612
Provides MC layer support for Zfbfmin: vector BF16 conversions.
Zvfbfmin does not appear to have a dependency on Zfbfmin as currently
specified.
Differential Revision: https://reviews.llvm.org/D147611
Provides MC layer support for Zfbfmin: scalar BF16 conversions.
As documented, this extension includes FLH, FSH, FMV.H.X, and FMH.X.H as
defined in Zfh/Zfhmin, but doesn't require either extension.
No Zfbfinxmin has been defined (though you would expect one in the
future, for symmetry with Zfhinxmin). See issue
https://github.com/riscv/riscv-bfloat16/issues/27.
Differential Revision: https://reviews.llvm.org/D147610
This reverts commit 65429b9af6a2c99d340ab2dcddd41dab201f399c.
Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards.
Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C"
This reverts commit 4072c8aee4c89c4457f4f30d01dc9bb4dfa52559.
Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump"
This reverts commit 7d47dac5f828efd1d378ba44a97559114f00fb64.
Make it clearer minnum(+0, +0) cannot return -0. Also remove
a note about the result always being quiet which is directly
contradicted by the following paragraph.
llvm-exegesis has both a capture mode and an analysis mode that can be
used independently of each other. This patch makes it clear that
analysis mode will work on other platforms that LLVM supports in the
documentation which was unclear before.
Reviewed By: courbet
Differential Revision: https://reviews.llvm.org/D150536
This patch changes two instances of an ampersand to a written out and
for more consistency with the rest of the file and brevity. In addition,
the last `cmake --build` reference is removed, again for consistency
with the rest of the file which shows the ninja invocations. This cmake
invocation also passed in the `--parallel` flag which doesn't make sense
with ninja using all threads by default.
This was changed in the previous patch to touch this line
(https://reviews.llvm.org/D88990), but if we want to change this, it
should be done across the entire file.
Currently, there is no documentation on what platforms and architectures
llvm-exegesis is supported on. This patch adds in user-facing
documentation in the CommandGuide about what architectures are supported
as well as developer facing documentation detailing the technical
reasons for why certain platforms are supported and some aren't.
This is a follow-up after discussion in
https://discourse.llvm.org/t/clarification-on-platform-support-for-llvm-exegesis/70206.
Reviewed By: kpdev42
Differential Revision: https://reviews.llvm.org/D149378
When the coroutine splitter splits swift coroutines, variables in the new
funclets are now described in terms of the frame pointer, which is always placed
at a ABI-specified register whose contents are valid upon function entry. As
such, debug intrinsics must be prepended by the `entry_value` operation.
Depends on D149778
Differential Revision: https://reviews.llvm.org/D149779
A follow up patch will make the CoroSplit pass introduce such operations in the
IR level when it is safe to do so.
Depends on D149748
Differential Revision: https://reviews.llvm.org/D149778
At the moment, we set the BC bit in DPP for both bound_ctrl:0 and
bound_ctrl:1, for compatibility with sp3 (see PR35397). However, this
hack is only needed for GFX8. For newer GFXs, sp3 behaves as expected,
i.e. it sets the bit when bound_ctrl:1 and clears it when bound_ctrl:0.
This patch updates LLVM to do the same for GFX11 or newer. We preserve
the current behaviour for GFX9 and 10 so we don't break any existing
code.
Differential Revision: https://reviews.llvm.org/D149254
Annotation metadata supports adding singular annotation strings to annotation block. This patch adds the ability to insert a tuple of strings into the metadata array.
The idea here is that each tuple of strings represents a piece of information that can be all related. It makes it easier to parse through related metadata information given it will be contained in one tuple.
For example in remarks any pass that implements annotation remarks can have different type of remarks and pass additional information for each.
The original behaviour of annotation remarks is preserved here and we can mix tuple annotations and single annotations for the same instruction.
Reviewed By: paquette
Differential Revision: https://reviews.llvm.org/D148328
This patch add the instructions of zcmp extension.
Instructions in zcmp extension try to optimise `mv` inst and the prologue & epilogue in functions
co-author: @Scott Egerton, @ZirconLiu, @Lukacma, @Heda Chen, @luxufan, @heyiliang, @liaochunyu
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D132819
The 1.0 vector spec PDF has text that says that Zve32f is compatible
with F or Zfinx and that Zve64d is compatible with D and Zdinx.
The references to *inx were removed from the spec in the github repository in
October 2021. The 1.0 pdf was made in September 2021.
Relevant commit 6fedb869e2
Reviewed By: jacquesguan
Differential Revision: https://reviews.llvm.org/D150021
They don't convey any useful information and make the documentation
unnecessarily hard to read.
Differential Revision: https://reviews.llvm.org/D149641
Re-land D145441 with data layout upgrade code fixed to not break OpenMP.
This reverts commit 3f2fbe92d0f40bcb46db7636db9ec3f7e7899b27.
Differential Revision: https://reviews.llvm.org/D149776
