ARM EHABI isn't signalled by any specific compiler builtin define,
but is implied by the lack of defines specifying any other
exception handling mechanism, `__USING_SJLJ_EXCEPTIONS__` or
`__ARM_DWARF_EH__`.
As Windows SEH also can be used for unwinding, check for the
`__SEH__` define too, in the same way.
This is the same change as 4a3722a2c3 /
D126866, applied on the clang headers.
Differential Revision: https://reviews.llvm.org/D126865
ARM EHABI isn't signalled by any specific compiler builtin define,
but is implied by the lack of defines specifying any other
exception handling mechanism, `__USING_SJLJ_EXCEPTIONS__` or
`__ARM_DWARF_EH__`.
As Windows SEH also can be used for unwinding, check for the
`__SEH__` define too, in the same way.
Differential Revision: https://reviews.llvm.org/D126866
In MinGW environments, thanks to slightly different code generation
and linker tricks, it's possible to link against a DLL C++ standard
library without dllimport attributes.
This allows using one single set of headers for linking against
either the DLL or a static library, leaving the decision entirely
up to the linking stage (where it can be switched with options like
-static-libstdc++).
This matches how libstdc++ headers work; there's no dllimport attributes
by default (unless the user has defined _GLIBCXX_DLL when including
headers).
This allows using one single set of headers while linking against
either a DLL or a static library, just like on Unix platforms.
This matches how libc++ has been used in MinGW configurations for
years (by first building the DLL, then configuring a static-only
build and installing on top, overwriting the libc++ config file
with one for static linking) by multiple MinGW toolchains, making
the dllimport-less use the de-facto tested configuration in the wild.
This also allows building all of libc++ in one single CMake
configuration, instead of having to do two separate builds on top of
each other.
(Linking against a DLL without dllimport can break if e.g. templates
use inconsistent visibility attributes - in cases where it still
works when using explicit dllimport; such a case was fixed in
948dd664c3 / D99932. With this as the
default configuration, we can catch such issues in CI.)
Differential Revision: https://reviews.llvm.org/D125924
In clang-cl/MSVC environments, linking against a DLL C++ standard
library requires having dllimport attributes in the headers; this
has been used for detecting whether the tests link against a DLL,
by looking at the libc++ specific define
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS.
In mingw environments, thanks to slightly different code generation
and a couple linker tricks, it's possible to link against a DLL C++
standard library without dllimport attributes. Therefore, don't
rely on the libc++ specific header define for the detection.
Replace the detection with a runtime test.
Differential Revision: https://reviews.llvm.org/D125922
This commit beefs up the documentation for MLIR language servers by
adding proper documentations/examples/etc for the provided PDLL
language server capabilities. Given that this documentation is also used
for the vscode extension, this commit also updates the user facing vscode
extension documentation.
Not that the images referenced in the new documentation are hosted on
the website, and will be commited to mlir-www shortly after this commit
lands.
Differential Revision: https://reviews.llvm.org/D125650
At the end of the codegen pipeline for DXIL we will emit the DXIL into
a global variable in the Module annotated for the "DXIL" section.
This will be used by the MCDXContainerStreamer to emit the DXIL into a
DXContainer DXIL part.
Other parts of the DXContainer will be constructed similarly by
serializing their values into GlobalVariables.
This will allow DXIL to flow into DXContainers through the normal
MCStreamer flow used in the MC layer.
Depends on D122270
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D125334
Summary:
Issue 55761:
Change the lit test for print-changed=dot-cfg to have a regular expression
for the template arguments portion of the name for a pass manager pass.
This part of the name can change because it is based on the name provided
by the compiler, which is implementation-dependent. This mimics the
other change printer tests.
Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: mgorny (Michal Gorny)
Differential Revision: https://reviews.llvm.org/D126876
Fixes a bug of us not correctly updating the terminator of the loop's
preheader, if multiple terminating branch instructions are present.
This is tested through existing tests. The bug itself is hard or not
possible to get exposed with the upstream Hexagon backend, because
the machine pipeliner checks for an existing preheader, which is
defined as a block with only 1 edge into the header.
The condition of this bug is a block into the loop with more than 1
edge, and not every downstream target checks for an existing preheader.
Differential Revision: https://reviews.llvm.org/D126386
This operation should be supported as a named op because
when the operands are viewed as having canonical layouts
with decreasing strides, then the "reduction" dimensions
of the filter (h, w, and c) are contiguous relative to each
output channel. When lowered to a matrix multiplication,
this layout is the simplest to deal with, and thus future
transforms/vectorizations of `conv2d` may find using this
named op convenient.
Differential Revision: https://reviews.llvm.org/D126995
Current BTF only supports 32-bit value. For example,
enum T { VAL = 0xffffFFFF00000008 };
the generated BTF looks like
.long 16 # BTF_KIND_ENUM(id = 4)
.long 100663297 # 0x6000001
.long 8
.long 18
.long 8
The encoded value is 8 which equals to (uint32_t)0xffffFFFF00000008
and this is incorrect.
This patch introduced BTF_KIND_ENUM64 which permits to encode
64-bit value. The format for each enumerator looks like:
.long name_offset
.long (uint32_t)value # lower-32 bit value
.long value >> 32 # high-32 bit value
We use two 32-bit values to represent a 64-bit value as current
BTF type subsection has 4-byte alignment and gaps are not permitted
in the subsection.
This patch also added support for kflag (the bit 31 of CommonType.Info)
such that kflag = 1 implies the value is signed and kflag = 0
implies the value is unsigned. The kernel UAPI enumerator definition is
struct btf_enum {
__u32 name_off;
__s32 val;
};
so kflag = 0 with unsigned value provides backward compatability.
With this patch, for
enum T { VAL = 0xffffFFFF00000008 };
the generated BTF looks like
.long 16 # BTF_KIND_ENUM64(id = 4)
.long 3187671053 # 0x13000001
.long 8
.long 18
.long 8 # 0x8
.long 4294967295 # 0xffffffff
and the enumerator value and signedness are encoded correctly.
Differential Revision: https://reviews.llvm.org/D124641
This change finishes fleshing out the ObjectYAML tools to support
converting DXContainer files into yaml representations.
Depends on D124944
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D124945
Patch adds new GICombineRules for G_ADD:
G_ADD(x, G_SUB(y, x)) -> y
G_ADD(G_SUB(y, x), x) -> y
Patch additionally adds new combine tests for AArch64 target for
these new rules.
Reviewed by: paquette
Differential Revision: https://reviews.llvm.org/D87936
This change adds support for promoting `linalg` operation operands that
are produced by rank-reducing `memref.subview` ops.
Differential Revision: https://reviews.llvm.org/D127086
list(POP_FRONT) is only added to cmake in 3.15, while our base line
version is 3.13
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D127129
Move the code that was added for D126896 after the normal recursive calls
to computeKnownBits. This allows us to calculate trailing zeros.
Previously we would break out of the switch before the recursive calls.
Currently, unary expressions involving valarray will create a temporary.
This leads to dangling references in expressions like `-a * b`, because
`-a` is a temporary and the resulting expression will refer to it. This
patch fixes the problem by creating a lazy expression to perform the unary
operation instead of eagerly creating a temporary valarray. This is
permitted by the Standard, which does not specify the exact type of
most expressions involving valarrays.
This is technically an ABI break, however I believe the actual potential
for breakage is very low.
rdar://90152242
Differential Revision: https://reviews.llvm.org/D125019
Using the pointer type analysis we can re-constitute typed pointers and
populate the correct types in the bitcasts throughout the IR.
This doesn't yet handle all cases, but this should be illustrative as
to the dirction and feasability of
the solution.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D122270
Includes dpp instructions and vop1/vop2 promoted to vop3
Patch 17/N for upstreaming of AMDGPU gfx11 architecture
Depends on D126483
Reviewed By: rampitec, #amdgpu
Differential Revision: https://reviews.llvm.org/D126917
gfx11 adds the ability to use dpp modifiers on vop3 instructions.
This patch adds machine code layer support for that. The MCCodeEmitter
is changed to use APInt instead of uint64_t to support these wider
instructions.
Patch 16/N for upstreaming of AMDGPU gfx11 architecture
Depends on D126475
Reviewed By: rampitec, #amdgpu
Differential Revision: https://reviews.llvm.org/D126483
Instead of providing two different constructors for iterators that
support the debug mode, provide a single constructor but leave the
container parameter unused when the debug mode is not enabled.
This allows simplifying all the call sites to unconditionally pass
the container, which removes a bunch of duplication in the container's
implementation.
Note that this patch does add some complexity to std::span, however
that is only because std::span has the ability to use raw pointers
as iterators instead of __wrap_iter. In retrospect, I believe it was
a mistake to provide that capability, and so it will be removed in a
future patch, along with the complexity added by this patch.
Differential Revision: https://reviews.llvm.org/D126993
In D115737 I found that I needed to teach Instruction::isSafeToRemove()
about strictfp/constrained intrinsics. It was pointed out that this is
probably the wrong function to use isInstructionTriviallyDead(). It doesn't
make sense to have a "second, worse implementation".
I also believe that the Instruction class is the wrong place for this
functionality. The information about whether or not an instruction can be
removed is in the transform passes and should stay there.
Differential Revision: https://reviews.llvm.org/D118387
This is a follow-up of https://reviews.llvm.org/D125832
(see also https://reviews.llvm.org/D125788 for more context). It simply
removes any remaining references to the `flang` bash script. Note that
that `flang-to-external-fc` remains intact.
This felt worthwhile mentioning in the release notes, which have not
been updated since LLVM 12 (we are approaching LLVM 15 now). I took the
liberty of removing all of the out-dated content and added a note about
the renaming.
Differential Revision: https://reviews.llvm.org/D127094
Currently, Clang accepts this code in C mode (where the tag is required
to be used) but rejects it in C++ mode thinking that the association is
defining a new type.
void foo(void) {
struct S { int a; };
_Generic(something, struct S : 1);
}
Clang thinks this in C++ because it sees struct S : when parsing the
class specifier and decides that must be a type definition (because the
colon signifies the presence of a base class type). This patch adds a
new declarator context to represent a _Generic association so that we
can distinguish these situations properly.
Fixes#55562
Differential Revision: https://reviews.llvm.org/D126969
This adds a fold of add(x, shuffle(x, <1,0,3,2,5,4,...>), into
shuffle(addp(x), <0,0,1,1,2,2,..>. The ADDP instruction takes two
vectors and returns one, adding adjacent pairs. So we match x in a
custom combine as it is lowered from a v8i32. The original code
would be 2 rev64 and 2 add, with the new code being a single addp
with a zip1;zip2 shuffle, producing smaller code.
Differential Revision: https://reviews.llvm.org/D126686
OpenMP 5.0 adds a new clause `in_reduction` on OpenMP directives.
This patch adds parser support for the same.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D124156
Support allocation of huge stack frame(>2g) on PPC64.
For ELFv2 ABI on Linux, quoted from the spec 2.2.3.1 General Stack Frame Requirements
> There is no maximum stack frame size defined.
On AIX, XL allows such huge frame.
Reviewed By: #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D107886
Try to simplify BranchOnCount to `BranchOnCond true` if TC <= UF * VF.
This is an alternative to D121899 which simplifies the VPlan directly
instead of doing so late in code-gen.
The potential benefit of doing this in VPlan is that this may help
cost-modeling in the future. The reason this is done in prepareToExecute
at the moment is that a single plan may be used for multiple VFs/UFs.
There are further simplifications that can be applied as follow ups:
1. Replace inductions with constants
2. Replace vector region with regular block.
Fixes#55354.
Depends on D126679.
Reviewed By: Ayal
Differential Revision: https://reviews.llvm.org/D126680
Martin Storsjö