[cross-project-tests] Make clang optional if not in LLVM_ENABLE_PROJECTS

Also mark debuginfo_tests as UNSUPPORTED if clang can't be found and
remove it from the list of test dependencies if not in
LLVM_ENABLE_PROJECTS.

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

Reviewed by: aprantl

[cross-project-tests] Add lld as a dependency if in LLVM_ENABLE_PROJECTS

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

Reviewed by: aprantl

[cross-project-tests] Rename vars to make sense for new directory name

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

Reviewed by: aprantl

[RFC][debuginfo-test] Rename debug-info lit tests for general purposes

Discussion thread:
https://lists.llvm.org/pipermail/llvm-dev/2021-January/148048.html

Move debuginfo-test into a subdirectory of a new top-level directory,
called cross-project-tests. The new name replaces "debuginfo-test" as an
LLVM project enabled via LLVM_ENABLE_PROJECTS.

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

Reviewed by: aprantl

[LoopVectorize] Fix strict reductions where VF = 1

Currently we will allow loops with a fixed width VF of 1 to vectorize
if the -enable-strict-reductions flag is set. However, the loop vectorizer
will not use ordered reductions if `VF.isScalar()` and the resulting
vectorized loop will be out of order.

This patch removes `VF.isVector()` when checking if ordered reductions
should be used. Also, instead of converting the FAdds to reductions if the
VF = 1, operands of the FAdds are changed such that the order is preserved.

Reviewed By: david-arm

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

[VPlan] Merge predicated-triangle regions, after sinking.

Sinking scalar operands into predicated-triangle regions may allow
merging regions. This patch adds a VPlan-to-VPlan transform that tries
to merge predicate-triangle regions after sinking.

Reviewed By: Ayal

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

[lld][MachO] Temporarily require 64 bit build for dead-strip.s

This test has always failed on 32 bit armv8 bots:
https://lab.llvm.org/buildbot/#/builders/178/builds/42

Due to the output order of some symbols changing.
I don't think this is an Arm specific issue so disabling
on 32 bit while it's investigated.

[hwasan] Show sp in register dump.

Reviewed By: hctim, eugenis

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

[clang-tidy][NFC] Fix buildbot failures in 'bugprone-easily-swappable-parameters'

[gn build] Port 499e39c5983d

[clang-tidy] Suppress reports to patternedly named parameters in 'bugprone-easily-swappable-parameters'

While the original check's purpose is to identify potentially dangerous
functions based on the parameter types (as identifier names do not mean
anything when it comes to the language rules), unfortunately, such a plain
interface check rule can be incredibly noisy. While the previous
"filtering heuristic" is able to find many similar usages, there is an entire
class of parameters that should not be warned about very easily mixed by that
check: parameters that have a name and their name follows a pattern,
e.g. `text1, text2, text3, ...`.`

This patch implements a simple, but powerful rule, that allows us to detect
such cases and ensure that no warnings are emitted for parameter sequences that
follow a pattern, even if their types allow for them to be potentially mixed at a call site.

Given a threshold `k`, warnings about two parameters are filtered from the
result set if the names of the parameters are either prefixes or suffixes of
each other, with at most k letters difference on the non-common end.
(Assuming that the names themselves are at least `k` long.)

 - The above `text1, text2` is an example of this. (Live finding from Xerces.)
 - `LHS` and `RHS` are also fitting the bill here. (Live finding from... virtually any project.)
 - So does `Qmat, Tmat, Rmat`. (Live finding from I think OpenCV.)

Reviewed By: aaron.ballman

Differential Revision: http://reviews.llvm.org/D97297

[clang-tidy] Suppress reports to similarly used parameters in 'bugprone-easily-swappable-parameters'

There are several types of functions and various reasons why some
"swappable parameters" cannot be fixed with changing the parameters' types, etc.
The most common example might be int `min(int a, int b)`... no matter what you
do, the two parameters must remain the same type.

The **filtering heuristic** implemented in this patch deals with trying to find
such functions during the modelling and building of the swappable parameter
range.
If the parameter currently scrutinised matches either of the predicates below,
it will be regarded as **not swappable** even if the type of the parameter
matches.

Reviewed By: aaron.ballman

Differential Revision: http://reviews.llvm.org/D78652

[clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions

Adds a relaxation option ModelImplicitConversions which will make the check
report for cases where parameters refer to types that are implicitly
convertible to one another.

Example:

    struct IntBox { IntBox(int); operator int(); };
    void foo(int i, double d, IntBox ib) {}

Implicit conversions are the last to model in the set of things that are
reasons for the possibility of a function being called the wrong way which is
not always immediately apparent when looking at the function (signature or
call).

Reviewed By: aaron.ballman, martong

Differential Revision: http://reviews.llvm.org/D75041

[clang-tidy] Extend 'bugprone-easily-swappable-parameters' with optionally considering differently qualified types mixable

Adds a relaxation option QualifiersMix which will make the check report for
cases where parameters refer to the same type if they only differ in qualifiers.

This makes cases, such as the following, not warned about by default, produce
a warning.

    void* memcpy(void* dst, const void* src, unsigned size) {}

However, unless people meticulously const their local variables, unfortunately,
even such a function carry a potential swap:

    T* obj = new T; // Not const!!!
    void* buf = malloc(sizeof(T));

    memcpy(obj, buf, sizeof(T));
    //     ^~~  ^~~ accidental swap here, even though the interface "specified" a const.

Reviewed By: aaron.ballman

Differential Revision: http://reviews.llvm.org/D96355

[clang-tidy] Extend 'bugprone-easily-swappable-parameters' with `typedef` and `const &` diagnostics

The base patch only deals with strict (canonical) type equality, which is
merely a subset of all the dangerous function interfaces that we intend to
find.
In addition, in the base patch, canonical type equivalence is not diagnosed in
a way that is immediately apparent to the user.

This patch extends the check with two features:

 * Proper typedef diagnostics and explanations to the user.
 * "Reference bind power" matching.

Case 2 is a necessary addition because in every case someone encounters a
function `f(T t, const T& tr)`, any expression that might be passed to either
can be passed to both. Thus, such adjacent parameter sequences should be
matched.

Reviewed By: aaron.ballman

Differential Revision: http://reviews.llvm.org/D95736

[clang-tidy] Add 'bugprone-easily-swappable-parameters' check

Finds function definitions where parameters of convertible types follow
each other directly, making call sites prone to calling the function
with swapped (or badly ordered) arguments.

Such constructs are usually the result of inefficient design and lack of
exploitation of strong type capabilities that are possible in the
language.

This check finds and flags **function definitions** and **not** call
sites!

Reviewed By: aaron.ballman, alexfh

Differential Revision: http://reviews.llvm.org/D69560

[clang][ARM] Mark sanitize-coverage-old-pm.c unsupported on armv7l

Our v7 Linux bots report the arch as "armv7l", not "armv7".

[mlir][linalg] Remove the StructuredOp capture mechanism.

After https://reviews.llvm.org/D104109, structured ops support scalar inputs. As a result, the capture mechanism meant to pass non-shaped parameters got redundant. The patch removes the capture semantics after the FillOp migrated to use scalar operands https://reviews.llvm.org/D104121.

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

[ARM] Add an extra fold for f32 extract(vdup(i32))

This adds another small fold for extract of a vdup, between a i32 and a
f32, converting to a BITCAST. This allows some extra folding to happen,
simplifying the resulting code.

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

[llvm-objdump] Print memory operand addresses as regular comments

The patch reuses the common code to print memory operand addresses as
instruction comments. This helps to align the comments and enables using
target-specific comment markers when `evaluateMemoryOperandAddress()` is
implemented for them.

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

[llvm-objdump] Prefix memory operand addresses with '0x'

This helps to avoid ambiguity when the address contains only digits 0..9.

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

[llvm-objdump] Prevent variable locations to overlap short comments

For now, the source variable locations are printed at about the same
space as the comments for disassembled code, which can make some ranges
for variables disappear if a line contains comments, for example:

                                        ┠─ bar = W1
0:  add x0, x2, #2, lsl #12     // =8192┃
4:  add z31.d, z31.d, #65280    // =0xff00
8:  nop                                 ┻

The patch shifts the report a bit to allow printing comments up to
approximately 16 characters without interferences.

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

[llvm-objdump] Print comments for the disassembled code

LLVM disassembler can generate comments for disassembled instructions.
The patch enables printing these comments for 'llvm-objdump -d'.

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

Revert "[M68k][GloballSel] Formal arguments lowering in IRTranslator"

This reverts commit 8f43407a07f015ca9a7543c6a0b5bde3918f9a0e due to
failure on its associated test.

Revert "[Test] Add XFAIL test for PR50918"

This reverts commit af03f7fb37bf13ed923f893182fd4e2f6c40bfd2.

Looks like the test is passing in some architectures. Reverting to green.

[LSR][NFC] Make sure that after the canonicalization the formula is canonical

[Test] Add XFAIL test for PR50918

[LoopDeletion] Benefit from branches by undef conditions when symbolically executing 1st iteration

We can exploit branches by `undef` condition. Frankly, the LangRef says that
such branches are UB, so we can assume that all outgoing edges of such blocks
are dead.

However, from practical perspective, we know that this is not supported correctly
in some other places. So we are being conservative about it.

Branch by undef is treated in the following way:
- If it is a loop-exiting branch, we always assume it exits the loop;
- If not, we arbitrarily assume it takes `true` value.

Differential Revision: https://reviews.llvm.org/D104689
Reviewed By: nikic

[PowerPC] Add XL Compat fetch builtins

Prototype
```
unsigned int __fetch_and_add (volatile unsigned int* addr, unsigned int
val);
unsigned long __fetch_and_addlp (volatile unsigned long* addr, unsigned
long val);
```
Ref:
https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.1?topic=functions-fetch

Reviewed By: #powerpc, w2yehia, lkail

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

[LLDB] Silence warnings in cli-wrapper-mpxtable.cpp

cli-wrapper-mpxtable.cpp was emitting warnings from printfs of
uint64_t on 32 bit arm build. This patch makes affected printfs
in cli-wrapper-mpxtable.cpp portable accross targets variants.

Tag sanitize-coverage-old-pm.c unsupported on arm 32 bit

This test is again failing across multiple bots and passing on others
there is no reliable way to enable it for some of the bots while
disabling for the unsupported ones. Tagging it as unsupported across all
types of Arm 32 bit cores.

[M68k][GloballSel] Formal arguments lowering in IRTranslator

Implementation of formal arguments lowering in the IRTranslator for the
M68k backend

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

Remove XFAIL flag from sanitize-coverage-old-pm.c

This test has started passing consistently on 32bit arm where underlying
core is reported as Armv7 or Thumbv7.
However it still fails intermittently on 32bit AArch32 reported as Armv8l.

https://lab.llvm.org/buildbot/#/builders/190/builds/20
https://lab.llvm.org/buildbot/#/builders/170/builds/41

PR50708: Update link to Intel SIMD ABI

PR37255: DebugInfo: LTO with -g inlined into -gmlt combined with Split DWARF without CU cross-references

A combination of features ^ that lead to a mismatch of expectations
about how a subprogram definition DIE would be produced with/without a
declaration when taking full -g debug info and inlining it into a -gmlt
CU - specifically when using Split DWARF that doesn't support cross-CU
references, so we have to put the -g debug info into the -gmlt CU, which
gets confusing about which mode is respected.

This patch comes down on respecting the CU the debug info is emitted
into, rather than preserving the full debug info when it's emitted into
the gmlt CU.

[RISCV] Add tests for __builtin_parity idiom.

We use (and (ctpop X), 1) to represent parity.

The generated code for i32 parity on RV64 has more instructions than
necessary which I hope to improve in a followup patch.

Also add missing test for i64 ctpop.

[BitCode] Add noprofile to getAttrFromCode()

After D104475 / D104658, building the Linux kernel with ThinLTO is
broken:

ld.lld: error: Unknown attribute kind (73) (Producer: 'LLVM13.0.0git'
Reader: 'LLVM 13.0.0git')

getAttrFromCode() has never handled this attribute so it is written
during the ThinLTO phase but it cannot be handled during the linking
phase.

Add noprofile to getAttrFromCode() so that disassembly works properly.

Reviewed By: MaskRay

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

[DSE] Preserve address space

Preserve address space when inserting i8* cast.

[MemCpyOpt] Preserve address space

Preserve address space when generating the cast to i8*.

Revert "[RISCV] Use zexti32/sexti32 in srliw/sraiw isel patterns to improve usage of those instructions."

I thought this might help with another optimization I was
thinking about, but I don't think it will. So it just wastes
compile time calling computeKnownBits for no benefit.

This reverts commit 81b2f95971edd47a0057ac4a77b674d7ea620c01.

[DSE] Support opaque pointers

For the start shortening optimization, always use a i8 type for
the GEP, as it is a raw offset calculation.

Handling of non-i8* memset/memcpy arguments requires insertion
of casts. These cases were previously miscompiled, as the offset
calculation was performed on the wrong type.

[Bazel] Update for 0813700de1

Updates Bazel BUILD files for changes in
https://github.com/llvm/llvm-project/commit/0813700de1

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

[clang-format] Fix the issue that empty lines being removed at the beginning of namespace

This is a bug fix of https://bugs.llvm.org/show_bug.cgi?id=50116

Reviewed By: MyDeveloperDay

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

[MemCpyOpt] Handle unusual memcpy element type

Apparently, it is legal to use memcpy/memset with pointer types
other than i8*. Prior to 81fcdae68c5ff656c30032fd26c6a21af4c51dbb
this case was silently miscompiled, as the i8 offset calculation
was performed on some other type. Now it would crash due to a
type mismatch. Fix this by inserting an explicit bitcast to i8*.

[InstCombine] hoist min/max intrinsics above select with constant op

This is an extension of the handling for unary intrinsics and
follows the logic that we use for binary ops.

We don't canonicalize to min/max intrinsics yet, but this might
help unlock other folds seen in D98152.

[MemCpyOpt] Support opaque pointers

[LoadStoreVectorizer] Support opaque pointers

There are remaining redundant bitcasts.

[VPlan] Track both incoming values for first-order recurrence phis.

This patch updates VPWidenPHI recipes for first-order recurrences to
also track the incoming value from the back-edge. Similar to D99294,
which did the same for reductions.

Reviewed By: Ayal

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

[InstCombine][test] add tests for min/max intrinsics with select operand; NFC

[Analysis] improve function signature checking for calloc

This would crash later if we thought the parameters were
valid for the standard library call as shown in:
https://llvm.org/PR50846

[Orc][examples] LLJITWithRemoteDebugger: fix CMake when utils are not built

[lld/mac] Don't fold UNWIND_X86_64_MODE_STACK_IND unwind entries

libunwind uses unwind info to find the function address belonging
to the current instruction pointer. libunwind/src/CompactUnwinder.hpp's
step functions read functionStart for UNWIND_X86_64_MODE_STACK_IND
(and for nothing else), so these encodings need a dedicated entry
per function, so that the runtime can get the stacksize off the
`subq` instrunction in the function's prologue.

This matches ld64.

(CompactUnwinder.hpp from https://opensource.apple.com/source/libunwind/
also reads functionStart in a few more cases if `SUPPORT_OLD_BINARIES` is set,
but it defaults to 0, and ld64 seems to not worry about these additional
cases.)

Related upstream bug: https://crbug.com/1220175

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

Fix lld testsuite after llvm-dwarfdump now errors on invalid DWARF

D104271 broke buildbots for lld/test/ELF/non-abs-reloc.s .

llvm-dwarfdump: Print warnings on invalid DWARF

llvm-dwarfdump was silent even when the format of DWARF was invalid
and/or llvm-dwarfdump did not understand/support some of the constructs.
This can be pretty confusing as llvm-dwarfdump is a tool for DWARF
producers+consumers development.

Review comments also by @dblaikie.

Reviewed By: jhenderson

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

[mlir][NFC] Cleanup: Move helper functions to StaticValueUtils

Reduce code duplication: Move various helper functions, that are duplicated in TensorDialect, MemRefDialect, LinalgDialect, StandardDialect, into a new StaticValueUtils.cpp.

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

[X86] Tighten up some inline assembly constraint handling.

Don't allow vectors to split into GPRs for 'r' and other scalar
constraints. Prevents assertion in getCopyToPartsVector.

Makes PR50907 give a better error instead of crashing.

[docs][llvm-strip] Fix documentation for -s/-S

Fix the command line guide for -g/-s/-S.
In particular, previously it was incorrectly stating that -S is an alias for --strip-all.

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

[X86] Correct the conversion of VALIGND/Q intrinsics to shufflevector.

We need to mask the immediate to the width of a single vector
rather than 2 vectors. If we use the width of 2 vectors then
any shift larger than the length of 1 vector is going to overflow
the shuffle indices.

Fixes PR50895.

[Driver] do not link _p libs for -pg on FreeBSD 14 and later

In FreeBSD 14 the project will deprecate the _p special profiling
libraries.

Support for -pg (i.e., mcount) still exists but libraries compiled
with -pg will not be built by default, so stop linking against them.

Reviewed by: Dimitry Andric
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.llvm.org/D104753

[ARM] Lower MVETRUNC to stack operations

The MVETRUNC node truncates two wide vectors to a single vector with
narrower elements. This is usually lowered to a series of extract/insert
elements, going via GPR registers. This patch changes that to instead
use a pair of truncating stores and a stack reload. This cuts down the
number of instructions at the expense of some stack space.

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

[clang] add C++ feature test macro for P2266 simpler implicit move

The feature was implemented in D99005, but we forgot to add the test
macro.

Reviewed By: Quuxplusone

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

[ARM] Introduce MVETRUNC ISel lowering

Currently, when encountering store(trunc(..)) where the trunc is double
a legal vector lenth in MVE, we spilt the node into two different stores
each performing half of the trunc from the wider type. This works well
for efficiently lowering wider than legal types, else the trunc becomes
a series of individual lane moves. Unfortunately this splitting is
currently one of the first combines attempted, so can happen before any
other combines which might be more preferable.

This patch instead introduces the concept of a MVETRUNC ISel node that
the trunk is initially lowered to, to keep it intact as a single item as
opposed to splitting it up. This allows us to push the store(trunc(..))
combine later, allowing other optimisations to potentially happen on the
trunc first. The store(trunc(..)) splitting can then be done later in
the legalisation period if needed, or else fall back to a buildvector as
before.

This can also be used in the future to lower to loads/stores, as opposed
to the more expensive lane extracts/inserts. Some extra combines are
added to keep all the existing tests happy.

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

[RISCV] Use zexti32/sexti32 in srliw/sraiw isel patterns to improve usage of those instructions.

[ARM] MVE vabd

This adds MVE lowering for VABDS/VABDU, using the code parted from
AArch64 in D91937.

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

[ISel] Port AArch64 SABD and UABD to DAGCombine

This ports the AArch64 SABD and USBD over to DAG Combine, where they can be
used by more backends (notably MVE in a follow-up patch). The matching code
has changed very little, just to handle legal operations and types
differently. It selects from (ABS (SUB (EXTEND a), (EXTEND b))), producing
a ubds/abdu which is zexted to the original type.

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

[Verifier] Support masked load/store with opaque pointers

[gn build] Port 8b7881a084d0

[clang-format] Add basic support for formatting JSON

I find as I develop I'm moving between many different languages C++,C#,JavaScript all the time. As I move between the file types I like to keep `clang-format` as my formatting tool of choice. (hence why I initially added C# support  in {D58404}) I know those other languages have their own tools but I have to learn them all, and I have to work out how to configure them, and they may or may not have integration into my IDE or my source code integration.

I am increasingly finding that I'm editing additional JSON files as part of my daily work and my editor and git commit hooks are just not setup to go and run [[ https://stedolan.github.io/jq/ | jq ]], So I tend to go to  [[ https://jsonformatter.curiousconcept.com/ | JSON Formatter ]] and copy and paste back and forth. To get nicely formatted JSON. This is a painful process and I'd like a new one that causes me much less friction.

This has come up from time to time:

{D10543}
https://stackoverflow.com/questions/35856565/clang-format-a-json-file
https://bugs.llvm.org/show_bug.cgi?id=18699

I would like to stop having to do that and have formatting JSON as a first class clang-format support `Language` (even if it has minimal style settings at present).

This revision adds support for formatting JSON using the inbuilt JSON serialization library of LLVM, With limited control at present only over the indentation level

This adds an additional Language into the .clang-format file to separate the settings from your other supported languages.

Reviewed By: HazardyKnusperkeks

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

[clang-format] [PR50702] Lamdba processing does not respect AfterClass and AfterNamespace

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

I believe {D44609} may be too aggressive with brace wrapping rules which doesn't always apply to Lamdbas

The introduction of BeforeLambdaBody and AllowShortLambdasOnASingleLine has impact on brace handling on other block types, which I suspect we didn't see before as people may not be using the BeforeLambdaBody  style

From what I can tell this can be seen by the unit test I change as its not honouring the orginal LLVM brace wrapping style for the `Fct()` function

I added a unit test from PR50702 and have removed some of the code (which has zero impact on the unit test, which kind of suggests its unnecessary), some additional attempt has been made to try and ensure we'll only break on what is actually a LamdbaLBrace

Reviewed By: HazardyKnusperkeks

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

[clang-format] PR50525 doesn't handle AlignConsecutiveAssignments correctly in some situations

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

AlignConsecutiveAssignments/Declarations cause incorrect alignment in the presence of a DesignatedInitializerPeriod (https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html)

```
static NTSTATUS stg(PLW_STREAM Stream, int identity)
{
     NTSTATUS             status;
     BYTE                 payload[256] = {'l', 'h', 'o', 't', 's', 'e'};
     struct dm_rpc_header header       = {.drh_magic        = DRH_MAGIC,
                                    .drh_op_code      = RPC_OP_ECHO,
                                    .drh_payload_size = sizeof(payload),
                                    .drh_body_size    = sizeof(payload),
                                    .drh_request_id   = 1};
     header.drh_version                = identity;
```

This fix addresses that by ensuring the period isn't ignored

Reviewed By: HazardyKnusperkeks

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

[ARM] Regenerate big-endian-vector-caller.ll test checks. NFC

[LV] Adjust trip count based on IsOrdered in widenPHIInstruction (NFC).

Suggested in D104197, avoids the early exit.

[gn build] Port aff57ff24aca

[JITLink][ELF] Add generic ELFLinkGraphBuilder template.

ELFLinkGraphBuilder<ELFT> will hold generic parsing and LinkGraph-building code
that can be shared between JITLink ELF backends for different architectures.

For now it's just a stub. The plan is to incrementally move functionality down
from ELFLinkGraphBuilder_x86_64 into the new template.

[clang][tests] Specify unwindlib in aix-ld tests

Clang can be configured with a different default unwindlib, for example
gcc. In that case, -lunwind will not be present in the output.

Fix this by explicitly specifying libunwind as the unwindlib.

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

[RISCV][NFC] Combine the control flow for different RetOp of interrupt function

Reviewed By: frasercrmck

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

[Docs] Minor fixes with language extension docs

There were some issues in the patch https://reviews.llvm.org/D104198. I also forgot to address one comment. This patch addresses these.

Reviewed By: xgupta

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

[RISCV] Add DAG combine to detect opportunities to replace (i64 (any_extend (i32 X)) with sign_extend.

If type legalization is going to insert a sign_extend for other users
of X and we can fold the sign_extend into ADDW/MULW/SUBW, it is
better to replace the ANY_EXTEND so we don't end up with a separate
ADD/MUL/SUB instruction for the users of the ANY_EXTEND.

I'm only handling setcc uses right now, but there are other
instructions that force sign_extends like ashr.

There are probably other *W instructions we could use in addition
to ADDW/SUBW/MULW.

My motivating case was a loop terminating compare and a phi use
as seen in the new test file.

Reviewed By: asb

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

[MLIR][Sparse] Move `buildLattices` into Merger

This allows us to use `buildLattices` in the `Merger` unittests.

Reviewed By: aartbik

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

[ms] [llvm-ml] Disable C-style comments

[X86] Selecting fld0 for undefined value in fast ISEL.

When set opt-bisect-limit to some value that is less than ISel pass
in command line and CurBisectNum expired, "DAG to DAG" pass lower
its opt level to O0. However "processimpdefs" and "X86 FP Stackifier"
is not stopped due to the CurBisectNum expiration. So undefined fp0
is generated. This cause crash in the "X86 FP Stackifier" pass,
because Stackifier doesn't expect any undefined fp value.

Here is the scenario that cause compiler crash.

  successors: %bb.26
  liveins: $r14
    ST_FPrr $st0, implicit-def $fpsw, implicit $fpcw
    renamable $rdi = MOV64ri @.str.3.16422
    renamable $rdx = LEA64r %stack.6, 1, $noreg, 0, $noreg
    ADJCALLSTACKDOWN64 0, 0, 0, implicit-def $rsp, implicit-def dead
    $eflags, implicit-def $ssp, implicit $rsp, implicit $ssp
    dead $esi = MOV32r0 implicit-def dead $eflags, implicit-def $rsi
    CALL64pcrel32 @foo, implicit $rsp, implicit $ssp, implicit $rdi,
    implicit $rsi, implicit $rdx, implicit-def dead $fp0
    renamable $xmm0 = MOVSDrm_alt %stack.10, 1, $noreg, 0, $noreg :: (load 8
    from %stack.10)
    ADJCALLSTACKUP64 0, 0, implicit-def $rsp, implicit-def dead $eflags,
    implicit-def $ssp, implicit $rsp, implicit $ssp
    renamable $fp2 = CHS_Fp80 killed undef renamable $fp0, implicit-def
    $fpsw
    JMP_1 %bb.26
The CALL64pcrel32 mark fp0 dead, so llvm free the stack slot for fp0
and the stack become empty. In the late instruction CHS_Fp80, it use
undefined register fp0, the original code assume there must be a stack
slot for the src register (fp0) without respecting it is undefined,
so llvm report error.

We have some discussion in https://reviews.llvm.org/D104440 and we
decide to fix it in fast ISel. The fix is to lower undefined fp value to
zero value, so that it release the burden of "X86 FP Stackifier" pass.
Thank Craig for the suggestion and the initial patch to fix it.

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

Disable ReplaceLDS pass, patch up tests to match

Most tests passed with an extra argument to explicitly enable the pass.
One does not, deleted it as part of this change. I can't see why the codegen
would be different between default on and default off but switched on. It
can be retrieved from the project history.

This would be a revert, but git revert was not clean. Disabling the pass
and leaving it in tree is less likely to cause breakage elsewhere than
patching up the git revert conflicts on unfamiliar code. It'll be landed
without review, as @hsmhsm is believed unavailable at present.

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

[DFSan] Change shadow and origin memory layouts to match MSan.

Previously on x86_64:

  +--------------------+ 0x800000000000 (top of memory)
  | application memory |
  +--------------------+ 0x700000008000 (kAppAddr)
  |                    |
  |       unused       |
  |                    |
  +--------------------+ 0x300000000000 (kUnusedAddr)
  |       origin       |
  +--------------------+ 0x200000008000 (kOriginAddr)
  |       unused       |
  +--------------------+ 0x200000000000
  |   shadow memory    |
  +--------------------+ 0x100000008000 (kShadowAddr)
  |       unused       |
  +--------------------+ 0x000000010000
  | reserved by kernel |
  +--------------------+ 0x000000000000

  MEM_TO_SHADOW(mem) = mem & ~0x600000000000
  SHADOW_TO_ORIGIN(shadow) = kOriginAddr - kShadowAddr + shadow

Now for x86_64:

  +--------------------+ 0x800000000000 (top of memory)
  |    application 3   |
  +--------------------+ 0x700000000000
  |      invalid       |
  +--------------------+ 0x610000000000
  |      origin 1      |
  +--------------------+ 0x600000000000
  |    application 2   |
  +--------------------+ 0x510000000000
  |      shadow 1      |
  +--------------------+ 0x500000000000
  |      invalid       |
  +--------------------+ 0x400000000000
  |      origin 3      |
  +--------------------+ 0x300000000000
  |      shadow 3      |
  +--------------------+ 0x200000000000
  |      origin 2      |
  +--------------------+ 0x110000000000
  |      invalid       |
  +--------------------+ 0x100000000000
  |      shadow 2      |
  +--------------------+ 0x010000000000
  |    application 1   |
  +--------------------+ 0x000000000000

  MEM_TO_SHADOW(mem) = mem ^ 0x500000000000
  SHADOW_TO_ORIGIN(shadow) = shadow + 0x100000000000

Reviewed By: stephan.yichao.zhao, gbalats

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

[libc] Use __builtin_ctzll instead of __builtin_ctzl in elements_x86.h.

__builtin_ctzl takes an unsigned long argument which need not be 64-bit
long on all platforms. Using __builtin_ctzll, which takes an unsigned
long long argument, ensures that 64-bit values will be handled on a
wider range of platforms.

Without this change, the test corresponding to M512 fails in Windows.

Reviewed By: gchatelet

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

Revert "[InstCombine] Make indexed compare fold opaque ptr compatible"

This reverts commit 5cb20ef8a235c2027489a196bba27630ca21a00b.

Assertion failures with this patch were reported on
https://reviews.llvm.org/rG5cb20ef8a235, revert for now.

OpaquePtr: Reject 'ptr*' again when parsing textual IR

Bring back the testcase dropped in
1e6303e60ca5af4fbe7ca728572fd65666a98271 and get it passing by checking
explicitly for `ptr*` in LLParser. Uses `Type::isOpaquePointerTy()` from
ad4bb8280952c2cacf497e30560ee94c119b36e0.

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

[mlir][sparse] add print methods to Merger (for debugging)

Reviewed By: gussmith23

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

[clang] Stop providing builtin overload candidate for relational function pointer comparisons

Word on the grapevine was that the committee had some discussion that
ended with unanimous agreement on eliminating relational function pointer comparisons.

We wanted to be bold and just ban all of them cold turkey.
But then we chickened out at the last second and are going for
eliminating just the spaceship overload candidate instead, for now.

See D104680 for reference.

This should be fine and "safe", because the only possible semantic change this
would cause is that overload resolution could possibly be ambiguous if
there was another viable candidate equally as good.

But to save face a little we are going to:
* Issue an "error" for three-way comparisons on function pointers.
  But all this is doing really is changing one vague error message,
  from an "invalid operands to binary expression" into an
  "ordered comparison of function pointers", which sounds more like we mean business.
* Otherwise "warn" that comparing function pointers like that is totally
  not cool (unless we are told to keep quiet about this).

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith

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

[lldb] Use the non-locking variant of objc_copyRealizedClassList

Avoid standing the Objective-C runtime lock by calling
objc_copyRealizedClassList_nolock instead of objc_copyRealizedClassList.

We already guarantee that no other threads can run while we're running
this utility expression, similar to when we parse the data ourselves
from the gdb_objc_realized_classes struct.

Worst case this will crash if the list is getting edited, which won't do
any harm and we'll just try again later.

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

Add support for the NSMutableDictionary variant: "__NSFrozenDictionaryM"

This was an oversight of the commit: bb93483c119b92c1ec2b7a58505e21b9dce6a333 that
added support for the Frozen variants.  Also added a test case for the way that
currently produces one of these variants (a copy).

[NFC] Prefer ConstantRange::makeExactICmpRegion over makeAllowedICmpRegion

The implementation is identical, but it makes the semantics a bit more
obvious.

[ms] [llvm-ml] Add support for ALIGN, EVEN, and ORG directives

Match ML.EXE's behavior for ALIGN, EVEN, and ORG directives both at file level and in STRUCTs.

We currently reject negative offsets passed to ORG inside STRUCTs (in ML.EXE and ML64.EXE, they wrap around as for an unsigned 32-bit integer).

Also, if a STRUCT is declared using an ORG directive, no value of that type can be defined.

Reviewed By: thakis

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

Change PathMappingList::RemapPath to return an optional result (NFC)

This is an NFC modernization refactoring that replaces the combination
of a bool return + reference argument, with an Optional return value.

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

[SimplifyLibCalls] Fix memchr opt to use CreateLogicalAnd

This fixes a bug at LibCallSimplifier::optimizeMemChr which does the following transformation:

```
// memchr("\r\n", C, 2) != nullptr -> (1 << C & ((1 << '\r') | (1 << '\n')))
// != 0
//   after bounds check.
```

As written above, a bounds check on C (whether it is less than integer bitwidth) is done before doing `1 << C` otherwise 1 << C will overflow.
If the bounds check is false, the result of (1 << C & ...) must not be used at all, otherwise the result of shift (which is poison) will contaminate the whole results.
A correct way to encode this is `select i1 (bounds check), (1 << C & ...), false`  because select does not allow the unused operand to contaminate the result.
However, this optimization was introducing `and (bounds check), (1 << C & ...)` which cannot do that.

The bug was found from compilation of this C++ code: https://reviews.llvm.org/rG2fd3037ac615#1007197

Reviewed By: nikic

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

[OpenMP] Change OpenMPOpt to check openmp metadata

The metadata added in D102361 introduces a module flag that we can check
to determine if the module was compiled with `-fopenmp` enables. We can
now check for the precense of this instead of scanning the call graph
for OpenMP runtime functions.

Depends on D102361

Reviewed By: jdoerfert

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

[OpenMP] Add Module metadata for OpenMP compilation

This patch adds a module level metadata flag indicating that the module
was compiled with the `-fopenmp` flag. This will make it easier for
passes like OpenMPOpt to determine if it should be run.

Reviewed By: jdoerfert

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

[PowerPC] Disable combine 64-bit bswap(load) without LDBRX

This causes failures on the big endian bootstrap bot.
Disabling this combine temporarily until I can get a proper fix.

[analyzer] Fix assertion failure on code with transparent unions

rdar://76948312

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

[llvm-rc] Don't rewrite the arch in the default triple unless necessary

When the default target arch isn't one that is supported as a
windows target, we want to set a suitable architecture (so that
Clang tests that run plain 'llvm-rc' succeed checks for e.g.
"#ifdef _WIN32" even for llvm builds that default to e.g. ppc64).

But if the default target architecture is usable, don't rewrite it.
(Rewriting it, by e.g. "T.setArch(T.getArch())", normalizes the
spelling of the architecture, e.g. changing i686 to i386. Such a
change can make clang unable to find the right sysroot.)

This can't, unfortunately, practically be tested very well because
it is entirely dependent on the default triple of the llvm build.

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

[ELF] --sysroot: change sysrooted script to not fall back for an absolute path

Modify the D13209 logic: for a script inside the sysroot, if an absolute path
does not exist, report an error instead of falling back to the path without the
sysroot prefix.

This matches GNU ld, which makes sense to me: we don't want to find an arbitrary
file in the host.

Reviewed By: ikudrin

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