Reviewed By: craig.topper

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

This fixes an issue where the RHS and LHS the comparison operation
creating the predicate were swapped back and forth forever.

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

In addition to consistency, we'll hit a wall when 11.1.0 gets released, because
we cannot represent it with lit versioning scheme.

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

It depends on Orc types (SymbolLookupSet), so can't be part of OrcShared.

Previously uniqueCallSite could have race conditions between different
threads. Now it is accessed with an atomic RMW and will be unique
between different threads.

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

A previous patch has already changed getInstructionCost to return
an InstructionCost type. This patch changes the other various
getXXXCost functions to return an InstructionCost too. This is a
non-functional change - I've added a few asserts that the costs
are valid in places where we're selecting between vector call
and intrinsic costs. However, since we don't yet return invalid
costs from any of the TTI implementations these asserts should
not fire.

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

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

The dpbsud should be dpbssd.

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

This patch moves the parsing of `{Lang,CodeGen}Options` from `parseSimpleArgs` to the original `Parse{Lang,CodeGen}Args` functions.

This ensures all marshalled `LangOptions` are being parsed **after** the call `setLangDefaults`, which in turn enables us to marshall `LangOptions` that somehow depend on the defaults. (In a future patch.)

Now, `CodeGenOptions` need to be parsed **after** `LangOptions`, because `-cl-mad-enable` (a `CodeGenOpt`) depends on the value of `-cl-fast-relaxed-math` and `-cl-unsafe-math-optimizations` (`LangOpts`).

Unfortunately, this removes the nice property that marshalled options get parsed in the exact order they appear in the `.td` file. Now we cannot be sure that a TableGen record referenced in `ImpliedByAnyOf` has already been parsed. This might cause an ordering issues (i.e. reading value of uninitialized variable). I plan to mitigate this by moving each `XxxOpt` group from `parseSimpleArgs` back to their original parsing function. With this setup, if an option from group `A` references option from group `B` in TableGen, the compiler will require us to make the `CompilerInvocation` member for `B` visible in the parsing function for `A`. That's where we notice that `B` didn't get parsed yet.

Reviewed By: Bigcheese

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

Element sections will also need flags, so we shouldn't squat the
WASM_SEGMENT namespace.

Depends on D90948.

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

This patch changes to make call_indirect explicitly refer to the
corresponding function table, residualizing TABLE_NUMBER relocs against
it.

With this change, wasm-ld now sees all references to tables, and can
link multiple tables.

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

getuid() is not being called in this file anymore.

`ssize_t` is from POSIX and is not standard unfortunately.
Rewritting the code so it doesn't depend on it.

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

[libc++] [P0935] [C++20] Eradicating unnecessarily explicit default constructors from the standard library.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0935r0.html

Reviewed By: ldionne, #libc

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

Add vamoswap, vamoadd, vamoxor, vamoand, vamoor,
    vamomin, vamomax, vamominu, vamomaxu intrinsics.

Reviewed By: craig.topper, khchen

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

GCC warning:
```
In file included from /usr/include/string.h:495,
                 from /usr/include/c++/9/cstring:42,
                 from /llvm-project/llvm/include/llvm/ADT/Hashing.h:53,
                 from /llvm-project/llvm/include/llvm/ADT/ArrayRef.h:12,
                 from /llvm-project/llvm/include/llvm/MC/MCAsmBackend.h:12,
                 from /llvm-project/llvm/lib/MC/XCOFFObjectWriter.cpp:14:
In function ‘char* strncpy(char*, const char*, size_t)’,
    inlined from ‘{anonymous}::Section::Section(const char*, llvm::XCOFF::SectionTypeFlags, bool, {anonymous}::CsectGroups)’ at /llvm-project/llvm/lib/MC/XCOFFObjectWriter.cpp:146:12:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:34: warning: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ specified bound 8 equals destination size [-Wstringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
      |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

Reviewed By: hubert.reinterpretcast

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

OrcShared is the correct home for this header since Orc was split in
1d0676b5. (It should have been moved in that commit, but was overlooked).

Previously committed as 9e08e51a, and
reverted because a dependency commit was reverted. This incorporates the
following follow-on commits that were also reverted:

7e84aa1b by Simon Pilgrim
ed13d8c6 by me
95c7b6ca by Sam McCall
430d5d84 by Dave Zarzycki

to dependent declarations.

Treat an id-expression that names a local variable in a templated
function as being instantiation-dependent.

This addresses a language defect whereby a reference to a dependent
declaration can be formed without any construct being value-dependent.
Fixing that through value-dependence turns out to be problematic, so
instead this patch takes the approach (proposed on the core reflector)
of allowing the use of pointers or references to (but not values of)
dependent declarations inside value-dependent expressions, and instead
treating template arguments as dependent if they evaluate to a constant
involving such dependent declarations.

This ends up affecting a bunch of OpenMP tests, due to OpenMP
imprecisely handling instantiation-dependent constructs, bailing out
early instead of processing dependent constructs to the extent possible
when handling the template.

Previously committed as 8c1f2d15, and
reverted because a dependency commit was reverted.

the nested-name-specifier when determining whether a qualified type is
instantiation-dependent.

Previously reverted in 25a02c3d due to
causing us to reject some code. It turns out that the rejected code was
ill-formed (no diagnostic required).

if E is merely instantiation-dependent.

Previously reverted in 34e72a14;
re-committed with a fix to an issue that caused name mangling to assert.

Add nounwind attribute to avoid generating cfi instructions. Also make
global buffer 64 bytes align in lit test case.

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

As of 8dacca94, we sign extend the atomic loaded
operand for signed subword comparisons. However, the assumption that the other
operand is correctly sign extended doesn't always hold. This patch sign extends
the other operand if it needs to be sign extended.

This is a second fix for https://bugs.llvm.org/show_bug.cgi?id=30451

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

The C++ standard wording doesn't appear to properly handle the case
where a class inherits a default constructor from a base class. Various
properties of classes are defined in terms of the corresponding property
of the default constructor, and in this case, the class does not have a
default constructor despite being default-constructible, which the
wording doesn't handle properly.

This change implements a tentative fix for these problems, which has
also been proposed to the C++ committee: if a class would inherit a
default constructor, and does not explicitly declare one, then one is
implicitly declared.

This is a additional bug fix for c5be0e0c. The distance for
the spill instructions is wrong in previous patch.

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

This reverts commit 3bdf4507.

Post commit comments need to be addressed first.

This patch adds `A & (A && B)` -> `A && B`  (similarly for or + logical or)

Also, this patch adds `~(select C, (icmp pred X, Y), const)` -> `select C, (icmp pred' X, Y), ~const`.

Alive2 proof:
merge_and: https://alive2.llvm.org/ce/z/teMR97
merge_or: https://alive2.llvm.org/ce/z/b4yZUp
xor_and: https://alive2.llvm.org/ce/z/_-TXHi
xor_or: https://alive2.llvm.org/ce/z/2uYx_a

Reviewed By: nikic

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

Somehow commit 1f125015 added the
right code but with the wrong whitespace.

This patch teaches SimplifyCFG::SimplifyBranchOnICmpChain to understand select form of
(x == C1 || x == C2 || ...) / (x != C1 && x != C2 && ...) and optimize them into switch if possible.
D93065 has more context about the transition, including links to the list of optimizations being updated.

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

The code here is checking to see if two sets are identical.
OtherBlocksSet should point to OtherL->getBlocksSet() instead.

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

The implementation had a lot of boilerplate and was more complicated than
necessary. This NFC refactoring introduces a few macros to reduce code
duplication, and uses a consistent style and formatting for the whole file.

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

After much refactoring over the last 2 weeks to the reduction
matching code, I think this change is finally ready.

We effectively broke fmax/fmin vector reduction optimization
when we started canonicalizing to intrinsics in instcombine,
so this should restore that functionality for SLP.

There are still FMF problems here as noted in the code comments,
but we should be avoiding miscompiles on those for fmax/fmin by
restricting to full 'fast' ops (negative tests are included).

Fixing FMF propagation is a planned follow-up.

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

InstAliases don't need scheduling information so I'm not sure what
these lines were even doing. Especially since the records don't
have names.