This mechanism was used for a couple of purposes, but the primary one was keeping track of which predicates in a union might apply to an expression.  As these sets are small and agressively deduped, this has little value.

Requires keeping better track of sret types.

for sequence of character types.

Upstream type test. Upstream test. Fix tests.

Do not run on windows, as that is not an implemented target.

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

Reviewed By: eugenis

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

Even if the search is marked as terminated after only looking at
the first operand, we'd still look at the remaining operands
before actually ending the search.

This seems pointless and wasteful, let's not do that.

Since we don't greedily flatten `umin_seq(a, umin(b, c))` into `umin_seq(a, b, c)`,
just looking at the operands of the outer-level `umin` is not sufficient,
and we need to recurse into all same-typed `umin`'s.

That is the canonical expansion for umin_seq,
so we really should roundtrip it.

The current logic was: https://alive2.llvm.org/ce/z/j8muXk
but in reality the offset to the Y in the 'true' hand
does not need to exist: https://alive2.llvm.org/ce/z/MNQ7DZ
https://alive2.llvm.org/ce/z/S2pMQD

To catch that, instead of computing the Y's in both
hands and checking their equality, compute Y and C,
and check that C is 0 or 1.

Apparently we didn't have any tests for that codepath?

Pulled out of D106237, this replaces the X86ISD::AVG DAG node with the
generic ISD::AVGCEILU. It doesn't remove the detectAVGPattern method,
but the extra generic ISel matching does alter the existing test.

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

Reviewed By: eugenis

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

Section 10.2.2.4, paragraph 3 states that a procedure pointer with an explicit
interface must have the same characteristics as its target.  Previously, we
interpreted this as disallowing such pointers to point to procedures with
implicit interfaces.  But several other compilers allow this.

We make an exception for the case where the explicit interface cannot be
called via an implicit interface.

This change makes us allow this, also

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

Makes lld-link work in a non-MSVC shell by autodetecting MSVC toolchain. Also
adds support for /winsysroot and a few other switches.

All this is done by refactoring to share code with clang-cl's existing support
for the same.

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

Since the bot is broken due to hwasan issues, it's not auto updating the file lists.

this is the first step in unifying some of the logic between hwasan and
mte stack tagging. this only moves around code, changes to converge
different implementations of the same logic follow later.

Reviewed By: eugenis

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

This allows using GTEST_SKIP() to identify un-executed tests.

Found by the Rotten Green Tests project.

This allows using GTEST_SKIP() to identify un-executed tests.

Found by the Rotten Green Tests project.

BitcastToGEP had an opaque/typed pointer decision point, make sure it
exercises both sides.

Found by the Rotten Green Tests project.

If we assume `llvm.amdgcn.s.barrier` is aligned we may remove it and
cause OpenMP GPU applications on the AMD GPU to be stuck or wrongly
synchronized.

Reported by Carlo Bertolli.

[clang][OpaquePtr] Remove call to getPointerElementType() in CodeGenModule::GetAddrOfGlobalTemporary()

This is a follow up to 4f3f4d67
("sanitizer_common: fix __sanitizer_get_module_and_offset_for_pc signature mismatch")
which fixes a similar problem for msan build.

I am getting the following error compiling a unit test for code that
uses sanitizer_common headers and googletest transitively includes
sanitizer interface headers:

In file included from third_party/gwp_sanitizers/singlestep_test.cpp:3:
In file included from sanitizer_common/sanitizer_common.h:19:
sanitizer_interface_internal.h:41:5: error: typedef redefinition with different types
('struct __sanitizer_sandbox_arguments' vs 'struct __sanitizer_sandbox_arguments')
  } __sanitizer_sandbox_arguments;
common_interface_defs.h:39:3: note: previous definition is here
} __sanitizer_sandbox_arguments;

Reviewed By: melver

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

This lets us avoid redundant implication work in the constructor of SCEVUnionPredicate which simplifies an upcoming change.  If we're actually building a predicate via PSE, that goes through addPredicate which does include the implication check.

For pre-AVX512 targets, attempt to sign-extend a vXi1 condition mask to pass to a X86ISD::BLENDV node

Fixes Issue #53760

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

This ports the aarch64 combines for HADD and RHADD over to DAG combine,
so that they can be used in more architectures (notably MVE in a
followup patch). They are renamed to AVGFLOOR and AVGCEIL in the
process, to avoid confusion with instructions such as X86 hadd. The code
was also rewritten slightly to remove the AArch64 idiosyncrasies.

The general pattern for a AVGFLOORS is
  %xe = sext i8 %x to i32
  %ye = sext i8 %y to i32
  %a = add i32 %xe, %ye
  %r = lshr i32 %a, 1
  %t = trunc i32 %r to i8

An AVGFLOORU is equivalent with zext. Because of the truncate
lshr==ashr, as the top bits are not demanded. An AVGCEIL also includes
an extra rounding, so includes an extra add of 1.

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

```
always_inline foo() { }

bar () {

noinline foo();
}
```

We should prefer call site attribute over attribute on decl. This is fix for AlwaysInliner, similar fix is needed for normal Inliner (follow up).

Related to https://reviews.llvm.org/D119061

Reviewed By: aeubanks

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

This makes the test pass for any LLVM_VERSION_MAJOR/MINOR value. Vendors
override these, and they change every six months.

Reviewed By: ldionne, Quuxplusone, #libc

Spies: Mordante, mgorny, libcxx-commits, arichardson, llvm-commits, arphaman

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

This reverts commit 7605ca85.

It caused an assertion failure in Fuschia.

If a cast is needed when replacing uses with newly created values, the
cast must be inserted after the instruction that defines the new value.

Fixes: SWDEV-321215

Reviewed By: arsenm

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

Get it from the byval type instead.

This is important for compatibility with DialectConversion.

This is an alternative to D118667 that instead of fixing the store
to match phase 1, it tries to detect the mismatch with the expected
value at the end of the block. This inserts a vsetvli after the vse
to satisfy the requirement of the other basic block.

We still have serious design issues in the pass, that is going to
require some rethinking.

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

Revert "[RISCV] Fix a vsetvli insertion bug involving loads/stores." and "[RISCC] Add missing words to comment. NFC"

This reverts commit f943c58c.
and commit 7eb78107.

This introduced a new bug that appears to be easier to hit.

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

We're missing a vsetvli before a vse after a redsum in this test.

This appears to be because the vmv.s.x has a VL of 1, but did not
trigger a vsetvli because it is a scalar move op and any non-zero
VL would work. So it looked at it the predecessors and decided it was
that they all had a non-zero vl. Then the redsum was visited, it
also took the VL from the predecessors since the vmv.s.x and the 4
was found compatible.

Finally we visit the vse and it looks at the BBLocalInfo and sees
that is compatible because it contains a VL of 1 from the vmv.s.x,
the first instruction in the block. BBLocalInfo was not updated
when the vredsum was visited because BBLocalInfo was valid and no
vsetvli was generated.

I think fundamentally the vmv.s.x optimization has the same first
phase and third phase not matching problem that D118667 was trying
to fix for stores.

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