Instantiation pattern is null for incomplete template types and using
specializaiton decl results in not seeing re-declarations.

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

This structure is supposed to be trivial, so we cannot simply do
"= nullptr;" on the new member. Doing that means you are non trivial,
regardless of whether you emulate the previously implied constructor somehow.

The next option is to update every use of brace initialisation.

Given that this is some hundreds of lines, this change just adds a dummy
pointer that is set to nullptr. Subsequent changes will actually use that
to point to register flags information.

Note: This change is not clang-format-ted because it changes a bunch of
areas that are not themselves formatted. It would just add noise.

Reviewed By: jasonmolenda, JDevlieghere

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

[TTI][X86] getMinMaxCost - use existing float minnum/maxnum intrinsic cost values instead of maintaining a duplicate cost table

Without fastmath (nnan) flags, minnum/maxnum must perform isnan handling as well as fmin/fmax - meaning the costs are notably higher, this is correctly handled in getIntrinsicInstrCost but was missing from the getMinMaxCost cost tables (which assumed fastmath).

Followup to 63c38953 which handled the integer cases

This adjusts some of the tests to use the architecture features directly as
opposed to -mcpu=cortex-m33 names.

Conversions to the LLVM dialect have an option to use the "bare pointer"
calling convention that converts memref types differently than the
default convention. It has crept into the conversion of operations that
are not related to calls but do require multiresult-to-struct packing.
Use a similar mechanism for the latter without using the calling
convention.

Reviewed By: gysit

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

This models the "flags" node from GDB's target XML:
https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html

This node is used to describe the fields of registers like cpsr on AArch64.

RegisterFlags is a class that contains a list of register fields.
These fields will be extracted from the XML sent by the remote.

We assume that there is at least one field, that the fields are
sorted in descending order and do not overlap. That will be
enforced by the XML processor (the GDB client code in our case).

The fields may not cover the whole register. To account for this
RegisterFields will add anonymous padding fields so that
sizeof(all fields) == sizeof(register). This will save a lot
of hasssle later.

Reviewed By: jasonmolenda, JDevlieghere

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

This patch recognizes when tensor.pack/unpack operations are simple
tensor.pad/unpad (a.k.a. tensor.extract_slice) and lowers them in a simpler
sequence of instruction.

For pack, instead of doing:
```
pad
expand_shape
transpose
```
we do
```
pad
insert_slice
```

For unpack, instead of doing:
```
transpose
collapse_shape
extract_slice
```
we do
```
extract_slice
```

Note: returning nullptr for the transform dialect is fine. The related
handles are just ignored by the following transformation.

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

These old patterns are not in use in either MLIR or downstream projects except for one test.
Additionally this is redundant with logic in the tensor.pad tiling implementation.

Drop SplitPaddingPatterns to reduce entropy.

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

[TTI] Remove unnecessary default CostKind args from getExtendedReductionCost/getMulAccReductionCost wrappers. NFC.

We should only ever call these from the TargetTransformInfo interface, which provides all the args.

Followup to D148149 where it was noticed that the std::optional wrapper wasn't helping with anything (we can just use an empty FastMathFlags()).

Be more robust, we shuold not crash  when we cannot find the corresponding token from the
tokenbuffer.

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

They had previously not followed the best practices; I must have
commited these in a rush. In particular, they used hard-coded SSA names
instead of patterns. This patch changes that, uses CHECK-DAG more
instead of CHECK-NEXT, and makes all function names unique.

Reviewed By: mehdi_amini

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

This PR introduces the `BrStack` member to store the info about
`loop`, `block`, `if` and `try`. It can check whether `br` immediate number
out of range.

Reviewed By: aheejin

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

Similar to the getArithmeticReductionCost / getExtendedReductionCost calls (which really don't need to use std::optional<>).

This will be necessary to correct recognize fast/nnan fmax/fmul reductions which can avoid nan handling - which will allow us to remove the fmax/fmin special case in X86TTIImpl::getMinMaxCost and use getIntrinsicInstrCost like we do for integer reductions (63c38953).

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

We can eliminate the or operation based on the predicate and the
relation between OrC and C.

sge: X | OrC s>= C --> X s>= 0 iff OrC s>= C s>= 0
sgt: X | OrC s>  C --> X s>= 0 iff OrC s>  C s>= 0
sle: X | OrC s<= C --> X s<  0 iff OrC s>  C s>= 0
slt: X | OrC s<  C --> X s<  0 iff OrC s>= C s>= 0

Alive2 links:
sge: https://alive2.llvm.org/ce/z/W-6FHE
sgt: https://alive2.llvm.org/ce/z/TKK2yJ
sle: https://alive2.llvm.org/ce/z/vURQGM
slt: https://alive2.llvm.org/ce/z/JAsVfw

Related issue: https://github.com/llvm/llvm-project/issues/61538



Signed-off-by: Jun Zhang <jun@junz.org>

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

Signed-off-by: Jun Zhang <jun@junz.org>

Repeatedly calling getName adds some overhead, which can be easily
avoided by querying the name just once per function. The improvements
are rather small (~0.5% back-end time in a compile-time optimized
setting), but also very easy to achieve.

Note that getting the name should be entirely avoidable in the common
case, but would require more substantial changes.

Reviewed By: MaskRay

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

Following a suggestion from Erich in https://reviews.llvm.org/D148101,
this patch bumps AS_GNU to 1 so that syntax 0 is invalid.  It also
asserts that the syntax is in range.

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

AttributeCommonInfo::isAlignasAttribute() was used in one place:
isCXX11Attribute().  The intention was for isAlignasAttribute()
to return true for the C++ alignas keyword.  However, as a FIXME
noted, the function also returned true for the C _Alignas keyword.
This meant that isCXX11Attribute() returned true for _Alignas as
well as for alignas.

AttributeCommonInfos are now always constructed with an
AttributeCommonInfo::Form.  We can use that Form to convey whether
a keyword is alignas or not.

The patch uses 1 bit of an 8-bit hole in the current layout
of AttributeCommonInfo.  This might not be the best long-term design,
but it should be easy to adapt the layout if necessary (that is,
if other uses are found for the spare bits).

I don't know of a way of testing this (other than grep -c FIXME)

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

This patch adds static functions for constructing most
AttributeCommonInfo::Forms.  Direct construction is only retained where
all fields (currently the syntax and spelling) are specified explicitly.

This is a wash on its own.  The purpose is to allow extra fields
to be added to Form without disrupting all callers.  In particular,
it allows extra information to be stored about keywords without
affecting non-keyword uses.

No functional change intended.

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

This patch adds an extra AttributeCommonInfo::Form constructor
for keywords, represented by their TokenKind.  This isn't a
win on its own, but it helps with later patches.

No functional change intended.

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

When constructing an attribute, the syntactic form was specified
using two arguments: an attribute-independent syntax type and an
attribute-specific spelling index.  This patch replaces them with
a single argument.

In most cases, that's done using a new Form class that combines the
syntax and spelling into a single object.  This has the minor benefit
of removing a couple of constructors.  But the main purpose is to allow
additional information to be stored as well, beyond just the syntax and
spelling enums.

In the case of the attribute-specific Create and CreateImplicit
functions, the patch instead uses the attribute-specific spelling
enum.  This helps to ensure that the syntax and spelling are
consistent with each other and with the Attr.td definition.

If a Create or CreateImplicit caller specified a syntax and
a spelling, the patch drops the syntax argument and keeps the
spelling.  If the caller instead specified only a syntax
(so that the spelling was SpellingNotCalculated), the patch
simply drops the syntax argument.

There were two cases of the latter: TargetVersion and Weak.
TargetVersionAttrs were created with GNU syntax, which matches
their definition in Attr.td, but which is also the default.
WeakAttrs were created with Pragma syntax, which does not match
their definition in Attr.td.  Dropping the argument switches
them to AS_GNU too (to match [GCC<"weak">]).

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

The purpose of this patch and follow-on patches is to ensure that
AttributeCommonInfos always have a syntax that is appropriate for
their kind (i.e. that it matches one of the entries in Attr.td).

The attribute-specific Create and CreateImplicit methods had four
overloads, based on their tail arguments:

(1) no extra arguments
(2) an AttributeCommonInfo
(3) a SourceRange
(4) a SourceRange, a syntax, and (where necessary) a spelling

When (4) had a spelling argument, it defaulted to
SpellingNotCalculated.

One disadvantage of this was that (1) and (3) zero-initialized
the syntax field of the AttributeCommonInfo, which corresponds
to AS_GNU.  But AS_GNU isn't always listed as a possibility
in Attr.td.

This patch therefore removes (1) and (3) and instead provides
the same functionality using default arguments on (4) (a bit
like the existing default argument for the spelling).
The default syntax is taken from the attribute's first valid
spelling.

Doing that raises the question: what should happen for attributes
like AlignNatural and CUDAInvalidTarget that are only ever created
implicitly, and so have no source-code manifestation at all?
The patch adds a new AS_Implicit "syntax" for that case.
The patch also removes the syntax argument for these attributes,
since the syntax must always be AS_Implicit.

For similar reasons, the patch removes the syntax argument if
there is exactly one valid spelling.

Doing this means that AttributeCommonInfo no longer needs the
single-argument constructors.  It is always given a syntax instead.

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

[compiler-rt] [test] [builtins] Pass the right parameters for linking with -nodefaultlibs on mingw targets

The clang-cl/MSVC case is handled above, thus consider win32 && !is_msvc
to be mingw.

This matches the list of libraries passed by e.g. the libcxx build, when
using -nodefaultlibs.

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

When we initialize the UnwindCursor (unw_cursor_t) based on
an existing Registers object (unw_context_t), we only initialize
a subset of the class.

Fill the struct properly for the current thread with RtlCaptureContext,
followed by overwriting of the subset of registers that we do have
available in the Registers class.

One might think that it's enough to initialize specifically the
registers that we signal availability for with ContextFlags,
however in practice, that's not enough.

This fixes crashes when restoring the context via RtlRestoreContext
(via UnwindCursor::jumpto), via __unw_resume.

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

This fixes libunwind_01.pass.cpp for x86_64 Windows.

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

This parameter isn't essential for the execution of this test, so just
skip it when running tests in mingw mode.

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

Mingw toolchains always end up referencing the malloc symbol due to
the CRT startup files.

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

This test uses lots of lld-link specific linker options that don't
work as such in mingw command lines.

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

In mingw mode on x86, long doubles are 80 bit - while MSVC mode uses
long doubles that are equal to regular doubles (on all architectures).

In the case of this formatting function, we're calling a MS CRT
provided printf function which interprets long doubles as 64 bit.

Since the long doubles are equal to regular doubles on all MSVC
platforms, just use regular double formatting. For MSVC environments
there's no difference, but for mingw environments, this avoids the
ambiguity.

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

This passes the same option that was added for MSVC builds in
fb5a24b4 in the corresponding mingw form too.

This fixes the BVGraph tests in the sanitizer unit tests.

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

When this header now is a fully regular header within the src tree,
give it a more regular name.

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

It seems that existing logic is too strict about latch block exit count.
It is required to be computable, however it is not used in any computations,
and effectively the only thing it is used for is to get the type of computed
exit count.

Sometimes the exit count for latch block is not known, but the loop is still
finite because of other exits, and safe bounds are still computable. In this case,
we miss an opportunity to apply IRCE.
We could instead use a more relaxed version - max symbolic exit count, which,
if exists, is enough to say that the loop is finite, and its type should be good enough.

There is a subtlety with type: we do not support latch count type wider than range
check type. Because of that, we want to have the narrowest type available. So if it
can be computed from latch block immediately, take it. Otherwise, take whatever whole
loop provides and hope that it's type isn't too wide.

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

This reverts commit 27c4777f.

It created problems for testing on Gentoo, see:
https://reviews.llvm.org/rG27c4777f41d2ab204c1cf84ff1cccd5ba41354da#1190273
Reverted until https://reviews.llvm.org/D147652 has been landed.

This was out of date and the link to the lldb tag will always be up to date.