Minor cleanup of redundant variable initialization and
if-condition. These are leftovers/oversights from previous
cleanup in this area:
* https://reviews.llvm.org/D72953
* https://reviews.llvm.org/D76808

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

In order to justify some of the special cases we have, we need to
assume that Op/RepOp are non-poison. For the places where this
function is used, if one of these is poison, then the select result
is poison anyway.

Do not assert if the bit width is larger than 64 bits. This case
is currently hidden from the IR layer by other checks, but gets
exposed with future changes.

Address review comment from https://reviews.llvm.org/D148947

This revision modifies the mem2reg interfaces and algorithm to be more
omfortable to use as a pattern. The motivation behind this is that
currently the pattern needs to be applied to the scope op of the region
in which allocators should be promoted. However, a more natural way to
apply the pattern would be to apply it on the allocator directly. This
is not only clearer but easier to parallelize.

This revision changes the mem2reg pattern to operate this way. This
required restraining the interfaces to only mutate IR using
RewriterBase, as the previously used escape hatch is not granular enough
to match on the region that is modified only. This has the unfortunate
cost of preventing batching allocator promotion and making the block
argument adding logic more complex. Because batching no longer made any
sense, I made the internal analyzer/promoter decoupling private again.

This also adds statistics to the mem2reg infrastructure.

Reviewed By: gysit

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

Define intersectWith and unionWith as two complementary ways of
combining KnownBits. The names are chosen for consistency with
ConstantRange.

Deprecate commonBits as a synonym for intersectWith.

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

All ops now support explicit type specification, update types to use
`!transform.any_op` instead of `!pdl.operation` for consistency.

Depends On D144515

Reviewed By: nicolasvasilache

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

Types have been introduced a while ago and provide for better
readability and transform-time verification. Use them in the ops from
the structured transform dialect extension.

In most cases, the types are appended as trailing functional types or a
derived format of the functional type that allows for an empty right
hand size without the annoying `-> ()` syntax (similarly to `func.func`
declaration that may omit the arrow). When handles are used inside mixed
static/dynamic lists, such as tile sizes, types of those handles follow
them immediately as in `sizes [%0 : !transform.any_value, 42]`. This
allows for better readability than matching the trailing type.

Update code to remove hardcoded PDL dependencies and expunge PDL from
structured transform op code.

Reviewed By: nicolasvasilache

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

Some tests were using liveins or IMPLICIT_DEFs to add fake live
registers, but that only works if you track liveness forwards. Add some
implicit uses too, so that it also works if you track liveness
backwards.

Some of these tests were using the regmask amdgpu_allvgprs but that is a
clobber not a use.

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

RegScavenger::backward is preferred because it does not rely on accurate
kill flags.

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

An instruction should be sunk (if otherwise legal and profitable) regardless
of if it has a dead def of a physreg or not. Physreg defs are checked in other
places and sinking is only done with dead defs of regs that are not live into
the target MBB.

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

Reviewed By: sebastian-ne, arsenm

This patch fixes a potential crash due to RegAllocFast not rewriting virtual
registers. This essentially happens because of a call to
MachineInstr::addRegisterKilled() in the process of allocating a "killed" vreg.
The former can eventually delete implicit operands without RegAllocFast
noticing, leading to some operands being "skipped" and not rewritten to use
physical registers.

Note that I noticed this crash when working on a solution for tying a register
with one/multiple of its sub-registers within an instruction. (See problem
description here:
https://discourse.llvm.org/t/pass-to-tie-an-output-operand-to-a-subregister-of-an-input-operand/67184).

Aside from this fix, I believe there could be further improvements to the
RegAllocFast when it comes to instructions with multiple uses of a same virtual
register. You can see it in the added test where the implicit uses have been
re-written in a somewhat surprising way because of phase ordering. Ultimately,
when allocating vregs for an instruction, I believe we should iterate on the
vregs it uses (and then process all the operands that use this vregs), instead
of directly iterating on operands and somewhat assuming each operand uses a
different vreg. This would in the end be quite close to what
greedy+virtregrewriter does. If that makes sense, I would probably spin off
another patch (after I get more familiar with RegAllocFast).

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

Representing matmuls as a sum of outer products is central to various
matrix extensions (e.g. Arm's SME). This test demonstrates how to use
Linalg's vectoriser and Vector's lowerings to represent `linalg.matmul`
as a chain of `vector.outerproduct` Ops.

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

The implementations for shifts were suboptimal in the case where
the max shift amount was >= bitwidth. In that case we should still
use the usual code clamped to BitWidth-1 rather than just giving up
entirely.

Additionally, there was an implementation bug where the known zero
bits for the individual shift amounts were not set in the shl/lshr
implementations. I think after these changes, we'll be able to drop
some of the code in ValueTracking which *also* evaluates all possible
shift amounts and has been papering over this issue.

For the "all poison" case I've opted to return an unknown value for
now. It would be better to return zero, but this has fairly
substantial test fallout, so I figured it's best to not mix it into
this change. (The "correct" return value would be a conflict, but
given that a lot of our APIs assert conflict-freedom, that's probably
not the best idea to actually return.)

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

Previously, we tried to check whether the -std=c++17 option was
supported and manually add the flag. That doesn't work for compilers
that do support C++17 but use a different option syntax, like
clang-cl.

OpenMP itself probably doesn't specifically require C++17, therefore
CXX_STANDARD_REQUIRED is left off, but in some cases, we may
have code that only works in C++17 mode.

In particular, 46262cab made a
refactoring that works when built with Clang in C++17 mode, but not
in C++14 mode. MSVC accepts the construct in both language modes.

For libomptarget, we've had specific checks that require C++17
(or the -std=c++17 option) to be supported. It's doubtful that
libomptarget has got any code which more specifically requires C++17;
this seems to be a remnant from when libomptarget was added
originally in 2467df6e / D14031.
At that point, the rest of OpenMP didn't require C++11, while
libomptarget did require it. Now, it's unlikely that anyone attempts
building it with a toolchain that doesn't support C++11.

At this point, we could also probably just set CXX_STANDARD_REQUIRED
to true, requiring C++17 as baseline for all the OpenMP libraries.

This fixes building OpenMP with clang-cl after
46262cab.

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

Reapply [clang] [test] Narrow down MSVC specific behaviours from "any windows" to only MSVC/clang-cl

This fixes running tests with a toolchain that defaults to a MinGW
target.

After the previous attempt with this patch, this is now changed to
use !defined(__MINGW32__) instead of defined(_MSC_VER) to distinguish
between MSVC and MinGW mode; Clang doesn't define _MSC_VER when invoked
with "clang -cc1" as some of those tests do.

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

Assume the MSVC style naming only for "windows-msvc" targets.

After the previous attempt, this was changed to use the host triple
instead of the target.

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

The revision adds a flag to mlir translate that suppresses
any non-error diagnostics. The flag is useful when importing
LLVM IR to LLVM dialect, which produces a lot of
warnings due to dropped metadata and debug intrinsics.

Reviewed By: Dinistro

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

Some file and directory related functions have an integer file descriptor argument
that can be a valid file descriptor or a special value AT_FDCWD. This value is
relatively often used in open source projects and is usually defined as a negative
number, and the checker reports false warnings (a valid file descriptor is not
negative) if this fix is not included.

Reviewed By: steakhal

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

Some relocations (e.g., R_RISCV_ALIGN) don't have a target symbol and
use a null symbol as a placeholder. These symbols were not processed
before making it impossible to create edges for them.

This patch tries to detect these null symbols and create absolute
symbols for them. Note that technically, these null symbols are UND in
the ELF file, not ABS, so it might make more consistent to create a new
symbol type for this (local undefined or so). However, since these
symbols are only used as placeholders (i.e., their values are never
used), I don't think it's worth the effort of doing this.

Also note that in the binaries that I have inspected, this null symbol
always has index 0. Could it make sense to add that to the test to avoid
accidentally adding unnecessary symbols? The reason I didn't do this
yet, is that I couldn't find any references in the specs that actually
guarantee this.

Reviewed By: lhames

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

find_section used to match offsets equal to file_offset + size causing
offsets to sometimes be attributed to the wrong section.

Reviewed By: Amir

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

Summary: DWARF32 is not supported for XCOFF64 under non-integrated-as mode on AIX, because system assembler will fill the debug section lengths according to DWARF64 format. While in intergrated-as mode, XCOFF64 should be able to select the DWARF format.

Reviewed By: shchenz

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

The logic from line 633 to 640 is specific for ARM as the comments said, it will make all the targets will prefer to using instruction with more predicates when compiler do AsmMatching.
And for code from line 642 to 649, X86 want to use the order records written in source file to sort the instructions. So X86 could be affected by this logic. (These code could be arrived only by X86)
After change this, seems AVX instructions have not be affected but it exposed some other errors for instruction push and call.
CALLpcrel16 could not be used in 64 bit mode, we need add Predicate for it. And for push instruction, previously because pushi32 has predicates = [Not64bitmode], so it precede pushi16, which is incorrect here, we should get pushw here and it also align with gcc.

Reviewed By: skan

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

These aren't currently created from anything that has a passthru
operand. If we need to support this in the future, we should add
a policy operand to the ISD node definition.

Allow auto(x) to appear in a parenthesis
expression.

The pattern (auto( can appear as part of a declarator,
so the parser is modified to avoid the ambiguity,
in a way consistent with the proposed resolution to CWG1223.

Reviewed By: aaron.ballman, #clang-language-wg

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

This is follow up to 039b28e1 to fix a typo to make sure skipped
part of test is only skipped for AArch64 Windows platform.

These are regular comments, use double slashes.

Fixes an isel crash after 6e6bed57.

Add more tests so we have coverage for this.

The COPY inserted in the epilog block before return instruction as part
of ABI lowering, can get optimized during machine copy propagation if
the same register is used earlier in a wwm operation that demands the
prolog/epilog wwm-spill store/restore to preserve its inactive lanes.
With the spill restore in the epilog, the preceding COPY appears to be
dead during machine-cp. To avoid it, mark the same register as a tied-op
in the spill restore instruction to ensure a usage for the COPY.

Reviewed By: arsenm

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

Update the documentation to reference lldbassert rather than
lldb_assert. The latter is the implementation, which shouldn't be used
directly. Instead, users should use lldbassert which is the macro that
expands to assert or lldb_assert depending on the build type.

The MachineUA now queries the target to determine if a given register holds a
uniform value. This is determined using the corresponding register bank if
available, or by a combination of the register class and value type. This
assumes that the target is optimizing for performance by choosing registers, and
the target is responsible for any mismatch with the inferred uniformity.

For example, on AMDGPU, an SGPR is now treated as uniform, except if the
register bank is VCC (i.e., the register holds a wave-wide vector of 1-bit
values) or equivalently if it has a value type of s1.

 - This does not always work with inline asm, where the register bank or the
   value type might not be present. We assume that the SGPR is uniform, because
   it is not expected to be s1 in the vast majority of cases.
 - The pseudo branch instruction SI_LOOP is now hard-coded to be always
   divergent, although its condition is an SGPR.

Reviewed By: arsenm

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

Fixes https://github.com/llvm/llvm-project/issues/62715

If a select's condition is a trivial select:
```
%s = select %cond, i1 true, i1 false
```
Unswitch on %cond, rather than %s. This fixes crashes where there is a
disparity in finding candidates and and the transformation logic.

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