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



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

The revision adds the LLVM expect and expect.with.probability
intrinsics.

Reviewed By: Dinistro, ftynse

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

There is memory explosion when converting the body or initializer region of a large global variable, e.g. a constant array.

For example, when translating a constant array of 100000 strings:
```
llvm.mlir.global internal constant @cats_strings() {addr_space = 0 : i32, alignment = 16 : i64} : !llvm.array<100000 x ptr<i8>> {
    %0 = llvm.mlir.undef : !llvm.array<100000 x ptr<i8>>
    %1 = llvm.mlir.addressof @om_1 : !llvm.ptr<array<1 x i8>>
    %2 = llvm.getelementptr %1[0, 0] : (!llvm.ptr<array<1 x i8>>) -> !llvm.ptr<i8>
    %3 = llvm.insertvalue %2, %0[0] : !llvm.array<100000 x ptr<i8>>
    %4 = llvm.mlir.addressof @om_2 : !llvm.ptr<array<1 x i8>>
    %5 = llvm.getelementptr %4[0, 0] : (!llvm.ptr<array<1 x i8>>) -> !llvm.ptr<i8>
    %6 = llvm.insertvalue %5, %3[1] : !llvm.array<100000 x ptr<i8>>
    %7 = llvm.mlir.addressof @om_3 : !llvm.ptr<array<1 x i8>>
    %8 = llvm.getelementptr %7[0, 0] : (!llvm.ptr<array<1 x i8>>) -> !llvm.ptr<i8>
    %9 = llvm.insertvalue %8, %6[2] : !llvm.array<100000 x ptr<i8>>
    %10 = llvm.mlir.addressof @om_4 : !llvm.ptr<array<1 x i8>>
    %11 = llvm.getelementptr %10[0, 0] : (!llvm.ptr<array<1 x i8>>) -> !llvm.ptr<i8>
    %12 = llvm.insertvalue %11, %9[3] : !llvm.array<100000 x ptr<i8>>

    ... (ignore the remaining part)
}
```

where `@om_1`, `@om_2`, ... are string global constants.

Each time an operation is converted to LLVM, a new constant is created.
When it comes to `llvm.insertvalue`, a new constant array of 100000 elements is created and the old constant array (input) is not destroyed.
This causes memory explosion. We observed that, on a system with 128 GB memory, the translation of 100000 elements got killed due to using up all the memory.
On a system with 64 GB, 65536 elements was enough to cause the translation killed.

This patch fixes the issue by checking generated constants and destroyed them if there is no use.
By the fix, the translation of 100000 elements only takes about 1.6 GB memory, and finishes without any error.

Reviewed By: ftynse, kiranchandramohan

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

Reviewed By: jdoerfert

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

**Summary**

When filling out the LayoutInfo for a structure with the offsets
from DWARF, LLDB fills gaps in the layout by creating unnamed
bitfields and adding them to the AST. If we don't do this correctly
and our layout has overlapping fields, we will hat an assertion
in `clang::CGRecordLowering::lower()`. Specifically, if we have
a derived class with a VTable and a bitfield immediately following
the vtable pointer, we create a layout with overlapping fields.

This is an oversight in some of the previous cleanups done around this
area.

In `D76808`, we prevented LLDB from creating unnamed bitfields if there
was a gap between the last field of a base class and the start of a bitfield
in the derived class.

In `D112697`, we started accounting for the vtable pointer. The intention
there was to make sure the offset bookkeeping accounted for the
existence of a vtable pointer (but we didn't actually want to create
any AS...

[lldb][DWARFASTParserClang][NFC] Extract condition for unnamed bitfield creation into helper function

This patch adds a new private helper
`DWARFASTParserClang::ShouldCreateUnnamedBitfield` which
`ParseSingleMember` whether we should fill the current gap
in a structure layout with unnamed bitfields.

Extracting this logic will allow us to add additional
conditions in upcoming patches without jeoperdizing readability
of `ParseSingleMember`.

We also store some of the boolean conditions in local variables
to make the intent more obvious.

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

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
l...

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.