when passing -platform_version to the linker

The use of a valid SDK version is preferred over an empty SDK version
(0.0.0) as the system's runtime might expect the linked binary to contain
a valid SDK version in order for the binary to work correctly

rdar://66795188

These are added for compatibility with XLC.

Commit 70c433a1 added this
test case that has -stop-before that mentions a pass that is
only added for non-release builds. Add the requirement for asserts.

Getting my feet wet here as a new committer.

Correct misspelling in check-depends.pl.

Reviewed By: vitalybuka

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

Adopt my suggestion in https://reviews.llvm.org/D91426#2653926 ,
generalizing the ppc64 specific code.

GNU ld and glibc ld.so has a contract about the first few entries of .got .
There are somewhat complex conditions when the header is needed. This patch
switches to a simpler approach: add a header unconditionally if
_GLOBAL_OFFSET_TABLE_ is used or the number of entries is more than just the
header.

This adds the long overdue implementations of these functions
that have been part of the ABI document and are now part of
the "Power Vector Intrinsic Programming Reference" (PVIPR).

The approach is to add new builtins and to emit code with
the fast flag regardless of whether fastmath was specified
on the command line.

Differential revision: https://reviews.llvm.org/D101209

This reverts commit 43bc584d.

The commit broke the -DLLVM_ENABLE_MODULES=1 builds.

http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/31603/consoleFull#2136199809a1ca8a51-895e-46c6-af87-ce24fa4cd561

This reverts commit b623df3c93983c4512aa54f2c706716bdf865a90, as per
https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy.

Breakages observed downstream reported in:
https://reviews.llvm.org/D91722#2724321

Fixes exist in:
https://reviews.llvm.org/D101523
https://reviews.llvm.org/D101540

but haven't landed yet going into the weekend.

The problem is the following. With fast8, we broke an important
invariant when loading shadows.  A wide shadow of 64 bits used to
correspond to 4 application bytes with fast16; so, generating a single
load was okay since those 4 application bytes would share a single
origin.  Now, using fast8, a wide shadow of 64 bits corresponds to 8
application bytes that should be backed by 2 origins (but we kept
generating just one).

Let’s say our wide shadow is 64-bit and consists of the following:
0xABCDEFGH. To check if we need the second origin value, we could do
the following (on the 64-bit wide shadow) case:

 - bitwise shift the wide shadow left by 32 bits (yielding 0xEFGH0000)
 - push the result along with the first origin load to the shadow/origin vectors
 - load the second 32-bit origin of the 64-bit wide shadow
 - push the wide shadow along with the second origin to the shadow/origin vectors.

The combineOrigins would then select the second origin if the wide
shadow ...

This extends the early-ifcvt pass to avoid a few more cases where the resulting
select instructions would have matching operands.  Additionally, we now use TII
to determine "sameness" of the operands so that as TII gets smarter, so too
will ifcvt.

The attached test case was bugpoint-reduced down from CINT2000/252.eon in the
test-suite. See: https://clang.godbolt.org/z/WvnrcrGEn

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

Implements parts of:
    * P0896R4 The One Ranges Proposal`

Depends on D100269.

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

Related to PR50172.

Protects us against regressions after we will start doing cttz(zext(x)) -> zext(cttz(x)) transformation in the middle-end.

Reviewed By: craig.topper

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

To run llvm-lit manually from the command line:

    ./bin/llvm-lit -sv --param std=c++2b --param cxx_under_test=`pwd`/bin/clang \
        --param debug_level=1 ../libcxx/test/

Tests that currently fail with `debug_level=1` are marked `LIBCXX-DEBUG-FIXME`,
but my intent is to deal with all of them and leave no such annotations in
the codebase within the next couple weeks. (I have patches for all of them
in my local checkout.)

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

This line was confusing some people: it's not supposed to indicate
any kind of problem with the script, and I can't see any way it could
even help with troubleshooting. So, just silence it.

This reverts commit 3d27b5d2.

Broke one of the PPC tests, which I didn't see because I usually build with
only the x86/AARch64 targets enabled... oops.

https://lab.llvm.org/buildbot#builders/109/builds/13834

llvm/test/CodeGen/PowerPC/expand-foldable-isel.ll

This is a long overdue cleanup. Not every use is eliminated, I stuck to uses
that were directly being called from select(), and not the render functions.

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

This extends the early-ifcvt pass to avoid a few more cases where the resulting
select instructions would have matching operands.  Additionally, we now use TII
to determine "sameness" of the operands so that as TII gets smarter, so too
will ifcvt.

The attached test case was bugpoint-reduced down from CINT2000/252.eon in the
test-suite. See: https://clang.godbolt.org/z/WvnrcrGEn

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

The right symbol flag mask is ~0x7, not ~0xf.

Also emit string names for the other flags (we were missing some).

Reviewed By: #lld-macho, gkm

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

Relative look table converter pass caused an issue when full lto
is enabled (reported in https://reviews.llvm.org/D94355).
This patch disables that pass from full lto pre-link phase optimization
pipeline until the issue is fixed.

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

SIPreEmitPeephole did not try to remove redundant s_set_gpr_idx_*
instructions in blocks that end with a conditional branch instruction.
This seems like a simple oversight.

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

Use contains() to check set membership, and adjust an oddly
structured loop.

The current code can scan an unlimited number of instructions,
if the containing basic block is very large. The test case from
PR50155 contains a basic block with approximately 100k instructions.

To avoid this, limit the number of instructions we inspect. At
the same time, drop the limit on the number of basic blocks, as
this will be implicitly limited by the number of instructions as
well.

Before commit "sanitizer_common: introduce kInvalidTid/kMainTid"
asan invalid/unknown thread id was 0xffffff, so presumably we printed "T16777215".
Now it's -1, so we print T-1. Fix the test.
I think the new format is even better, "T-1" clearly looks like something special
rather than a random large number.

Reviewed By: vitalybuka

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

Patch by Viacheslav Nikolaev. Thanks!

Followup for D101428.

Reviewed By: dvyukov

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

This patch fixes a bug from D89802.  For example, without it, Clang
generates x as the debug map name for both x and y in the following
example:

```
 #pragma omp target map(to: x, y)
 x = y = 1;
```

Reviewed By: jhuber6

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

Eventually we'll use this flag to properly handle bl/blx
opcodes.

Reviewed By: #lld-macho, gkm

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

This just parses the `-arch armv7` and emits the right header flags.
The rest will be slowly fleshed out in upcoming diffs.

Reviewed By: #lld-macho, gkm

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

Mentioned in https://reviews.llvm.org/D96523.

This patch migrates the TTI cost interfaces to return an InstructionCost.

See this patch for the introduction of the type: https://reviews.llvm.org/D91174
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2020-November/146408.html

Reviewed By: sdesmalen, kparzysz

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

As discussed in https://lists.llvm.org/pipermail/llvm-dev/2021-April/150225.html,
the current comments for TracksLiveness property and isKill flag are confusing.
This patch makes the comments more clearer.

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

This introduces a flag that aborts if we ever reduce to IR that fails
the verifier.

Reviewed By: swamulism, arichardson

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

Reviewed By: fhahn, hans

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

This re-reverts one piece of 1b885573,
reapplying one piece of D101437 (but not the "service"-queue piece of it).

It turns out that the behavior of `grep [^ -~]`, or even `grep [A-Z]`,
depends on locale, specifically `LC_COLLATE`. So we want to make sure
we're not in any weird locale, no matter what machine we're running on.
Yes, "en_US.UTF-8" counts as weird!
https://stackoverflow.com/questions/67320156/misbehavior-of-gnu-grep-when-grepping-for-ignores-spaces
https://stackoverflow.com/questions/6799872/how-to-make-grep-a-z-independent-of-locale