The original proposal was adopted in Apr 2019, but was subsequently
updated by WG14 N2662 in June 2021. We already supported the attribute
on a label and it behaved as expected, but we had not bumped the
feature test value.

This reverts commit 35028d41.
Breaks tests on Windows, see https://reviews.llvm.org/D133549#3785952

This was happening for every iteration but only needs to be done once.

This is the common case and should be checked first. Provides a very
marginal compile time improvement on the example I'm looking at.

This addresses the failures found in:
https://lab.llvm.org/buildbot/#/builders/30/builds/25899

The original proposal was adopted in Apr 2019 and so the previous value
was 201904L. However, a subsequent proposal (N2448) was adopted to add
an optional message argument to the attribute. We already support that
functionality, but had not bumped the feature test value.

This construct is being tested for atomic operation based upon
the test 5.0/parallel_for_simd/test_parallel_for_simd_atomic.c
from the SOLLVE repo: https://github.com/SOLLVE/sollve_vv

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

The class set a SmallVector stack allocation size to 64 elements which
is uncommonly large. These structures are then used extensively and
copied often in functions which led to stack frame sizes considered
excessively large for some use cases.

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

If one of the operands is negated in a multiplication we can optimise the operation by moving the negation to the smallest operand or to the result

Reviewed By: fhahn

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

We should be able to efficiently use the vector version for scalar bitreverse, like we do for XOP.

This reverts commit d200db38, which causes a
clang crash. See https://reviews.llvm.org/D111283#3785755

Test case for convenience:
```
template <typename T>
using P = int T::*;

template <typename T, typename... A>
void j(P<T>, T, A...);

template <typename T>
void j(P<T>, T);

struct S {
  int b;
};
void g(P<S> k, S s) { j(k, s); }
```

This extends 4658366d to add a note
explaining why the register is reserved.

note: x13 is clobbered by asynchronous signals when using Arm64EC.

I've added testing for w/x registers and v/q/s/d and h floating point
registers.

llvm will accept, but silently do nothing with, b registers. So they
are not tested here (clang rejects them so at least for C you're safe anyway).

Reviewed By: efriedma

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

Some uses of std::make_pair and the std::pair's first/second members
in the ScheduleDAGInstrs.[cpp|h] files were replaced with using of the
vector's emplace_back along with structure bindings from C++17.

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

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

Ensure any uses of `image2d_depth_t` and `image2d_array_depth_t` are
guarded behind the `cl_khr_depth_images` extension in
`OpenCLBuiltins.td`.

Fix a few missing guards in `opencl-c.h`.

Reviewed By: reames

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

Causing:
https://github.com/llvm/llvm-project/issues/57709

This reverts commit ab56719a.

CompareToBlankPadding was doing signed compare on architecture where
`char` is signed. This caused `'abc'//char(128) > 'abc'` to evaluate
to false at runtime instead of true.

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

Add is a template parameter, so we can use constexpr if here.

Make stackRef() const as well and use that.

Make localRef() const and use that.

No need to include the full Pointer.h here.

References are implemented through pointers, so we need a second deref
when encountering a DeclRefExpr of a reference type.

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

This call is expensive, so don't perform it for zero indices.

Also rename the variable to use Alloc rather than Alloca, this
doesn't have anything to do with allocas in particular.

This is to reduce the diff in follow-up changes.

This attempts to stop the type promotion pass transforming where it is
not profitable, by not marking PhiNodes as ToPromote and being more
aggressive about pulling extends out of loops.

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

Set the EmulatedTLS option based on `Triple::hasDefaultEmulatedTLS()`
if the user didn't specify it; set `ExplicitEmulatedTLS` to true
in `llvm::TargetOptions` and set `EmulatedTLS` to Clang's
opinion of what the default or preference is.

This avoids any risk of deviance between the two.

This affects one check of `getCodeGenOpts().EmulatedTLS` in
`shouldAssumeDSOLocal` in CodeGenModule, but as that check only
is done for `TT.isWindowsGNUEnvironment()`, and
`hasDefaultEmulatedTLS()` returns false for such environments
it doesn't make any current testable difference - thus NFC.

Some mingw distributions carry a downstream patch, that enables
emulated TLS by default for mingw targets in `hasDefaultEmulatedTLS()`
- and for such cases, this patch does make a difference and fixes the
detection of emulated TLS, if it is implicitly enabled.

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

This patch refators the polynomial Approx test. Now we pass the constant as function argument to avoid constant folder.

Link: https://github.com/llvm/llvm-project/issues/57613

Reviewed By: Mogball

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

By this change the `exploded-graph-rewriter` will display the class kind
of the expression of the environment entry. It makes easier to decide if
the given entry corresponds to the lvalue or to the rvalue of some
expression.

It turns out the rewriter already had support for visualizing it, but
probably was never actually used?

Reviewed By: martong

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

Some select node Pattern with register cmp instruction should be guarded
by iHas2E3.

`LazyCompoundVals` should only appear as `default` bindings in the
store. This fixes the second case in this patch-stack.

Depends on: D132142

Reviewed By: xazax.hun

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

It turns out that in certain cases `SymbolRegions` are wrapped by
`ElementRegions`; in others, it's not. This discrepancy can cause the
analyzer not to recognize if the two regions are actually referring to
the same entity, which then can lead to unreachable paths discovered.

Consider this example:

```lang=C++
struct Node { int* ptr; };
void with_structs(Node* n1) {
  Node c = *n1; // copy
  Node* n2 = &c;
  clang_analyzer_dump(*n1); // lazy...
  clang_analyzer_dump(*n2); // lazy...
  clang_analyzer_dump(n1->ptr); // rval(n1->ptr): reg_$2<int * SymRegion{reg_$0<struct Node * n1>}.ptr>
  clang_analyzer_dump(n2->ptr); // rval(n2->ptr): reg_$1<int * Element{SymRegion{reg_$0<struct Node * n1>},0 S64b,struct Node}.ptr>
  clang_analyzer_eval(n1->ptr != n2->ptr); // UNKNOWN, bad!
  (void)(*n1);
  (void)(*n2);
}
```

The copy of `n1` will insert a new binding to the store; but for doing
that it actually must create a `TypedValueRegion` which it could pass to
the `LazyCompoundVal`. Since the memregion in question is a
`SymbolicRegion` - which is untyped, it needs to first wrap it into an
`ElementRegion` basically implementing this untyped -> typed conversion
for the sake of passing it to the `LazyCompoundVal`.
So, this is why we have `Element{SymRegion{.}, 0,struct Node}` for `n1`.

The problem appears if the analyzer evaluates a read from the expression
`n1->ptr`. The same logic won't apply for `SymbolRegionValues`, since
they accept raw `SubRegions`, hence the `SymbolicRegion` won't be
wrapped into an `ElementRegion` in that case.

Later when we arrive at the equality comparison, we cannot prove that
they are equal.

For more details check the corresponding thread on discourse:
https://discourse.llvm.org/t/are-symbolicregions-really-untyped/64406

---

In this patch, I'm eagerly wrapping each `SymbolicRegion` by an
`ElementRegion`; basically canonicalizing to this form.
It seems reasonable to do so since any object can be thought of as a single
array of that object; so this should not make much of a difference.

The tests also underpin this assumption, as only a few were broken by
this change; and actually fixed a FIXME along the way.

About the second example, which does the same copy operation - but on
the heap - it will be fixed by the next patch.

Reviewed By: martong

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