https://reviews.llvm.org/D92631

We should fix them, but let's XFAIL them for now so that we can start
running check-llvm on bots and lock in the passing tests.

Part of PR46647.

The original tests have unneeded symbols and copy-relocation-zero-abs-addr.s
does not actually test anything.

Rewrite them and add copy-relocation-zero-addr.s instead.

Add --soname=b so that the address 0x203400 will be stable.  (When linking an
executable with %t.so, the path %t.so will be recorded in the DT_NEEDED entry if
%t.so doesn't have DT_SONAME. .dynstr will have varying lengths on different
systems.)

macOS/arm is w^x, so these tests don't work. Fixes these failures:

  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.AllocAndRelease/5
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.AllocAndReleaseHuge/5
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.BasicWrite/5
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.DuplicateNear/5
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.EnabledWrite/3
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.EnabledWrite/4
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.EnabledWrite/5
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.MultipleAllocAndRelease/5
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.MultipleWrite/5
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.SuccessiveNear/5
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.UnalignedNear/5
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.ZeroNear/5
  LLVM-Unit :: Support/./SupportTests/AllocationTests/MappedMemoryTest.ZeroSizeNear/5

Part of PR46647.

[[GlobalISel][IRTranslator] Fix a crash when the use of an extractvalue is a non-dominated metadata use.

We don't expect uses to come before defs in the CFG, so allocateVRegs() asserted.

Fixes PR48211

[SimplifyCFG] FoldBranchToCommonDest(): bonus instrns must only be used by PHI nodes in successors (PR48450)

In particular, if the successor block, which is about to get a new
predecessor block, currently only has a single predecessor,
then the bonus instructions will be directly used within said successor,
which is fine, since the block with bonus instructions dominates that
successor. But once there's a new predecessor, the IR is no longer valid,
and we don't fix it, because we only update PHI nodes.

Which means, the live-out bonus instructions must be exclusively used
by the PHI nodes in successor blocks. So we have to form trivial PHI nodes.
which will then be successfully updated to recieve cloned bonus instns.

This all works fine, except for the fact that we don't have access to
the dominator tree, and we don't ignore unreachable code,
so we sometimes do end up having to deal with some weird IR.

Fixes https://bugs.llvm.org/show_bug.cgi?id=48450

Some of the pattern matching in PPCInstrVSX.td and node lowering involving vectors assumes 64bit mode.  This patch disables some of the unsafe pattern matching and lowering of BUILD_VECTOR in 32bit mode.

Reviewed By: Xiangling_L

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

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

Part of PR46644

CVP currently handles switches by checking an equality predicate
on all edges from predecessor blocks. Of course, this can only
work if the value being switched over is defined in a different block.

Replace this implementation with a call to getPredicateAt(), which
also does the predecessor edge predicate check (if not defined in
the same block), but can also do quite a bit more: It can reason
about phi-nodes by checking edge predicates for incoming values,
it can reason about assumes, and it can reason about block values.

As such, this makes the implementation both simpler and more
powerful. The compile-time impact on CTMark is in the noise.

We should fix them, but let's XFAIL them for now so that we can start
running check-clang on bots and lock in the passing tests.

Part of 46644.

These cover cases handled by getPredicateAt(), but not by the
current implementation:

 * Assumes based on context instruction.
 * Value from phi node in same block (using per-pred reasoning).
 * Value from non-phi node in same block (using block-val reasoning).

The getPayload/getMask/getPassThrough functions should return values
that could be composed into a masked load/store without any additional
type casts. The previous fix violated that.
Instead, convert scalar mask to a vector right before rescaling.

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

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

- Document which processors are supported by which runtimes.
- Add missing mappings for code object V2 note records

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

When printing verification errors for ops with the incorrect number of
operand segments, print the required number as well as the actual
number. Split off from D93005.

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

The last use of isLoop was removed on Apr 29, 2002 in commit
09bbb5c0 as part of an effort to
remove "old induction varaible cannonicalization pass built on top of
interval analysis".

AlignVectors treats all loaded/stored values as vectors of bytes,
and masks as corresponding vectors of booleans, so make getMask
produce a 1-element vector for scalars from the start.

This makes it possible to use update_llc_test_checks to manage tests
that check for incorrect x86 stack offsets. It does not yet modify any
test to make use of this new option.

The ABI demands a data16 prefix for lea in 64-bit LP64 mode, but not in
64-bit ILP32 mode. In both modes this prefix would ordinarily be
ignored, but the instructions may be changed by the linker to
instructions that are affected by the prefix.

Reviewed By: RKSimon

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

This adds some basic MVE masked load/store costs, notably changing the
cost of legal loads/stores to the MVECostFactor and the cost of
scalarized instructions to 8*NumElts.

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

When it comes to the scalar cost of any predicated block, the loop
vectorizer by default regards this predication as a sign that it is
looking at an if-conversion and divides the scalar cost of the block by
2, assuming it would only be executed half the time. This however makes
no sense if the predication has been introduced to tail predicate the
loop.

Original patch by Anna Welker

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

Background: Call to library arithmetic functions for div is emitted by the
compiler and it set wrong “C” calling convention for calls to these functions,
whereas library functions are declared with `spir_function` calling convention.
InstCombine optimization replaces such calls with “unreachable” instruction.
It looks like clang lacks SPIRABIInfo class which should specify default
calling conventions for “system” function calls. SPIR supports only
SPIR_FUNC and SPIR_KERNEL calling convention.

Reviewers: Erich Keane, Anastasia

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

Currently, the interpreter's context is not updated until a command is executed.
This has resulted in the behavior of SB-interface functions and some commands
depends on previous user actions. The interpreter's context can stay uninitialized,
point to a currently selected target, or point to one of previously selected targets.

This patch removes any usages of CommandInterpreter::UpdateExecutionContext.
CommandInterpreter::HandleCommand* functions still may override context temporarily,
but now they always restore it before exiting. CommandInterpreter saves overriden
contexts to the stack, that makes nesting commands possible.

Added test reproduces one of the issues. Without this fix, the last assertion fails
because interpreter's execution context is empty until running "target list", so,
the value of the global property was updated instead of process's local instance.

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

Replace loops with standard algorithms or range-based loops.

TargetList::CreateTarget automatically adds created target to the list, however,
CommandObjectTargetCreate does some additional preparation after creating a target
and which can fail. The command should remove created target if it failed. Since
the function has many ways to return, scope guard does this work safely.

Changes to the TargetList make target adding and selection more transparent.

Other changes remove unnecessary SetSelectedTarget after CreateTarget.

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

Support all the spellings of boolean datatypes according to https://yaml.org/type/bool.html

Reviewed By: silvas

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

This commit <https://reviews.llvm.org/rGe5158b52730d323bb8cd2cba6dc6c89b90cba452> introduced an accidental change, which renames `-faccess-control` and `-fno-access-control` to `-fno-access-control` and `-fno-no-access-control`.

Reviewed By: dexonsmith, MaskRay

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

This introduces more flexible multiclass for declaring two flags controlling the same boolean keypath.

Compared to existing Opt{In,Out}FFlag multiclasses, the new syntax makes it easier to read option declarations and reason about the keypath.

This also makes specifying common properties of both flags possible.

I'm open to suggestions on the class names. Not 100% sure the benefits are worth the added complexity.

Depends on D92774.

Reviewed By: dexonsmith

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

We don't need to always generate `-f[no-]experimental-new-pass-manager`.

This patch does not change the behavior of any other command line flag. (For example `-triple` is still being always generated.)

Reviewed By: dexonsmith, Bigcheese

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

Add more tests of the command line marshalling infrastructure.

The new tests now make a "round-trip": from arguments, to CompilerInvocation instance to arguments again in a single test case.

The TODOs are resolved in a follow-up patch.

Depends on D92830.

Reviewed By: dexonsmith

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