Currently, there is no way to disable ExpensiveCombines when doing
a standalone opt -instcombine run, as that's the default, and the
opt option can currently only be used to force enable, not to force
disable. The only way to disable expensive combines is via -O1 or -O2,
but that of course also runs the rest of the kitchen sink...

This patch allows using opt -instcombine -expensive-combines=0 to
run InstCombine without ExpensiveCombines.

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

This shows that -expensive-combines=0 is ignored.

This makes the local variable `implies` to have the correct
type to satisfy ArrayRef's constructor:

  /*implicit*/ constexpr ArrayRef(const T (&Arr)[N])

Hopefully this should please GCC 5.

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

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

RecursiveASTVisitor expects TraverseDecl to be implemented by
subclasses.

Right now every dataflow algorithm uses its own worklist implementation.
This is a first step to reduce this duplication. Some upcoming
algorithms such as the lifetime analysis is going to use the factored
out implementations.

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

Currently the lowering for i16 image coordinates asserts on gfx10. I'm
somewhat confused by this though. The feature is missing from the
gfx10 feature lists, but the a16 bit appears to be present in the
manual for MIMG instructions.

Revert rGb6437b35 - "Fix gcc9 "moving a local object in a return statement prevents copy elision" Wpessimizing-move warnings."

Fix buildbots

Revert rGff3fe145 "Fix gcc9 "moving a local object in a return statement prevents copy elision" Wpessimizing-move warning."

Fix buildbots

Fix gcc9 "moving a local object in a return statement prevents copy elision" Wpessimizing-move warning.

Fix gcc9 "moving a local object in a return statement prevents copy elision" Wpessimizing-move warnings.

This is another part of a problem noted in PR42024:
https://bugs.llvm.org/show_bug.cgi?id=42024

The AVX2 code may use awkward 256-bit shuffles vs. the AVX code that gets split
into the expected 128-bit unpack instructions. We have to be selective in
matching the types where we try to do this though. Otherwise, we can end up
with more instructions (in the case of v8x32/v4x64).

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

There was a change to trap1 instruction between v62 and v65. This
feature will allow the assembler/disassembler to handle different
variants depending on the CPU version.

Hopefully fixes: http://45.33.8.238/win/6040/step_4.txt

Fixes http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/13716

[clang-tidy] Disable Checks on If constexpr statements in template Instantiations for BugproneBranchClone and ReadabilityBracesAroundStatements

Summary: fixes [[ https://bugs.llvm.org/show_bug.cgi?id=32203 | readability-braces-around-statements broken for if constexpr]] and [[ https://bugs.llvm.org/show_bug.cgi?id=44229 | bugprone-branch-clone false positive with template functions and constexpr ]] by disabling the relevant checks on if constexpr statements while inside an instantiated template. This is due to how the else branch of an if constexpr statement is folded away to a null statement if the condition evaluates to false

Reviewers: alexfh, hokein, aaron.ballman, xazax.hun

Reviewed By: aaron.ballman, xazax.hun

Subscribers: rnkovacs, JonasToth, Jim, lebedev.ri, xazax.hun, cfe-commits

Tags: #clang-tools-extra, #clang

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

Most X87 compare instructions write to the X87 status word, while the SSE (U)COMI compares write to rFLAGS. These are often handled very differently on CPUs (e.g. rFLAGS outputs typically involve a fpu2gpr transfer), and we shouldn't be grouping all these instructions behind a single class - so this patch splits off the SSE compares into a new WriteFComX class (and currently keeps the same behaviours). If there's a need to distinguish between X87 instructions more closely we can investigate that in the future, but as we don't handle any of the X87 side effects at the moment its unlikely to have any notable effect.

[SelectionDAG] ComputeKnownBits - assert we're computing the 0'th (difference) result for the SUB/SUBC cases

Matches what we already do for the ADD/ADDC/ADDE case.

This patch adds bugprone-reserved-identifier, which flags uses of __names _Like
::_this, which are reserved for the implementation. The check can optionally be
inverted, i.e. configured to flag any names that are _not_ reserved, which may
be useful for e.g. standard library implementors.

We could argue that match() should be more flexible here,
but I'm not sure what impact that would have on existing code.

Introduce a method to walk through use-def chains to decide whether
it's possible to remove a given instruction and its users. These
instructions are then stored in a set until the end of the transform
when they're erased. This is now used to perform checks on the
iteration count (LoopDec chain), element count (VCTP chain) and the
possibly redundant iteration count.

As well as being able to remove chains of instructions, we know also
check that the sub feeding the vctp is producing the expected value.

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

In SPIR-V, when a new version is introduced, it is possible some
existing extensions will be incorporated into it so that it becomes
implicitly declared if targeting the new version. This affects
conversion target specification because we need to take this into
account when allowing what extensions to use.

For a capability, it may also implies some other capabilities,
for example, the `Shader` capability implies `Matrix` the capability.
This should also be taken into consideration when preparing the
conversion target: when we specify an capability is allowed, all
its recursively implied capabilities are also allowed.

This commit adds utility functions to query implied extensions for
a given version and implied capabilities for a given capability
and updated SPIRVConversionTarget to use them.

This commit also fixes a bug in availability spec. When a symbol
(op or enum case) can be enabled by an extension, we should drop
it's minimal version requi...

This reverts commit 397215cc because
this feature needs more discussion.

Blindly following unique-successors chain appeared to be a bad idea.
In a degenerate case when block jumps to itself that goes into endless loop.

Discovered this problem when playing with additional changes,
managed to reproduce it on existing LoopPredication code.

Fix by checking a "visited" set while iterating through unique successors.

Reviewed By: skatkov

Tags: #llvm

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

Summary:
tslint and tsc (the TypeScript compiler itself) use comment pragmas of
the style:

  // tslint:disable-next-line:foo
  // @ts-ignore

These must not be wrapped and must stay on their own line, in isolation.
For tslint, this required adding it to the pragma regexp. The comments
starting with `@` are already left alone, but this change adds test
coverage for them.

Reviewers: krasimir

Subscribers: cfe-commits

Tags: #clang

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

Summary:
Revision a75f8d98 fixed spacing for operators,
but caused the const and non-const versions to diverge:
```
// With Style.PointerAlignment = FormatStyle::PAS_Left:

struct A {
  operator char*() { return ""; }
  operator const char *() const { return ""; }
};

```
The code was checking if the type specifier was directly preceded by `operator`.
However there could be comments and `const/volatile` in between.

Reviewers: mprobst

Reviewed By: mprobst

Subscribers: cfe-commits

Tags: #clang

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

Implementing functions used to enable testing of memory instructions.

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

We already call it later in the method (which is in the right order as we Initialize it
at the of the constructor).

Summary:
Implements the following intrinsics:

    * @llvm.aarch64.sve.brka
    * @llvm.aarch64.sve.brka.z
    * @llvm.aarch64.sve.brkb
    * @llvm.aarch64.sve.brkb.z
    * @llvm.aarch64.sve.brkn.z
    * @llvm.aarch64.sve.brkpa.z
    * @llvm.aarch64.sve.brkpb.z

Reviewers: sdesmalen, efriedma, dancgr, mgudim, cameron.mcinally, rengolin

Reviewed By: sdesmalen

Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, llvm-commits

Tags: #llvm

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

Add DemandedElts handling to ISD::ANY_EXTEND and add missing ISD::ANY_EXTEND_VECTOR_INREG handling. Despite the lack of test changes this code IS being used - its just that the ANY_EXTEND ops are legalized later on (typically to ZERO_EXTEND equivalents) so we typically manage to combine later on.

GCC will accept any case for assembler directives.
For example ".abort" and ".ABORT" (even ".aBoRt")
are equivalent.

https://sourceware.org/binutils/docs/as/Pseudo-Ops.html#Pseudo-Ops
"The names are case insensitive for most targets,
and usually written in lower case."

Change llvm-mc to accept any case for generic directives
or aliases of those directives.

This for Bugzilla #39527.

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

Summary:
Several SVE intrinsics with immediate arguments (including those
added by D70253 & D70437) do not use the ImmArg property.
This patch adds ImmArg<Op> where required and changes
the appropriate patterns which match the immediates.

Reviewers: efriedma, sdesmalen, andwar, rengolin

Reviewed By: efriedma

Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, cfe-commits, llvm-commits

Tags: #llvm

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

In D71281 a fix was put in to round up the size of a ThunkSection to the
nearest 4KiB when performing errata patching. This fixed a problem with a
very large instrumented program that had thunks and patches mutually
trigger each other. Unfortunately it triggers an assertion failure in an
AArch64 allyesconfig build of the kernel. There is a specific assertion
preventing an InputSectionDescription being larger than 4KiB. This will
always trigger if there is at least one Thunk needed in that
InputSectionDescription, which is possible for an allyesconfig build.

Abstractly the problem case is:
.text : {
          *(.text) ;
          ...
          . = ALIGN(SZ_4K);
          __idmap_text_start = .;
          *(.idmap.text)
          __idmap_text_end = .;
          ...
        }
The assertion checks that __idmap_text_end - __idmap_start is < 4 KiB.
Note that there is more than one InputSectionDescription in the
OutputSection so we can't just restrict the fix to OutputSections smaller
than 4 KiB.

The fix presented here limits the D71281 to InputSectionDescriptions that
meet the following conditions:
1.) The OutputSection is bigger than the thunkSectionSpacing so adding
thunks will affect the addresses of following code.
2.) The InputSectionDescription is larger than 4 KiB. This will prevent
any assertion failures that an InputSectionDescription is < 4 KiB
in size.

We do this at ThunkSection creation time as at this point we know that
the addresses are stable and up to date prior to adding the thunks as
assignAddresses() will have been called immediately prior to thunk
generation.

The fix reverts the two tests affected by D71281 to their original state
as they no longer need the 4KiB size roundup. I've added simpler tests to
check for D71281 when the OutputSection size is larger than the ThunkSection
spacing.

Fixes https://github.com/ClangBuiltLinux/linux/issues/812

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

These files should do the more or less the same initialize/terminate calls in the
same order. This just reverts all the differences that have piled up over time
in the SystemInitializerTest that people keep forgetting about.