Unused for now, but will be used in later commits.

I'm involved with the Static Analyzer for the most part.
I think we should embrace newer language standard features and gradually
move forward.

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

No need to fill the buffer if no padding is added. I.e., the tensor.pad is packing only.

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

Summary: Currently, if there are multiple definitions of the same symbol declared has weak linkage, the linker may choose the wrong one when they are compiled with integrated-as. This patch fixes the issue. If the target symbol is a weak label we must not attempt to resolve the fixup directly. Emit a relocation and leave resolution of the final target address to the linker.

Reviewed By: shchenz

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

This patch introduces a new `CXXLifetimeExtendedObjectRegion` as a representation
of the memory for the temporary object that is lifetime extended by the reference
to which they are bound.

This separation provides an ability to detect the use of dangling pointers
(either binding or dereference) in a robust manner.
For example, the `ref` is conditionally dangling in the following example:
```
template<typename T>
T const& select(bool cond, T const& t, T const& u) { return cond ? t : u; }

int const& le = Composite{}.x;
auto&& ref = select(cond, le, 10);
```
Before the change, regardless of the value of `cond`, the `select()` call would
have returned a `temp_object` region.
With the proposed change we would produce a (non-dangling) `lifetime_extended_object`
region with lifetime bound to `le` or a `temp_object` region for the dangling case.

We believe that such separation is desired, as such lifetime extended temporaries
are closer to the variables. For example, they may have a static storage duration
(this patch removes a static temporary region, which was an abomination).
We also think that alternative approaches are not viable.

While for some cases it may be possible to determine if the region is lifetime
extended by searching the parents of the initializer expr, this quickly becomes
complex in the presence of the conditions operators like this one:
```
Composite cc;
// Ternary produces prvalue 'int' which is extended, as branches differ in value category
auto&& x = cond ? Composite{}.x : cc.x;

// Ternary produces xvalue, and extends the Composite object
auto&& y = cond ? Composite{}.x : std::move(cc).x;
```

Finally, the lifetime of the `CXXLifetimeExtendedObjectRegion` is tied to the lifetime of
the corresponding variables, however, the "liveness" (or reachability) of the extending
variable does not imply the reachability of all symbols in the region.
In conclusion `CXXLifetimeExtendedObjectRegion`, in contrast to `VarRegions`, does not
need any special handling in `SymReaper`.

RFC: https://discourse.llvm.org/t/rfc-detecting-uses-of-dangling-references/70731

Reviewed By: xazax.hun

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

This fixes a few custom printers which were printing IR that couldn't be
round-tripped.

Reviewed By: rriddle

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

Summary:
This was not added to dynamic_hsa.h

AMDGPU provides a fixed frequency clock since some generations back.
However, the frequency is variable by card and must be looked up at
runtime. This patch adds a new device environment line for the clock
frequency so that we can use it in the same way as NVPTX. This is the
correct implementation and the version in ASO should be replaced.

Reviewed By: tianshilei1992

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

This is consistent with the other classes in this file.
It avoids a possible name conflict with standard extensions or
other vendors in the future.

The patch handle masked.gather/scatter just like the way D149245 handles
vp.gather/scatter.

Reviewed By: craig.topper

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

In the initially commit, we limited the static archive to osx.

This patch removes that limitation.

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

Remove overrides of parseDirective that unconditionally return NoMatch.
This is what the base implementation does.

This is a follow-up to D154101 based on post-commit review feedback.

Use an APInt getter as the only interface to getting the value out of an
ExpressionValue. This paves the way to switch ExpressionValue to handle
any integer without causing too big of a patch.

Reviewed By: arichardson

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

Use APInt internally to store values represented by ExpressionValue.
This will allow to support any integer values in FileCheck numeric
expression in a subsequent commit.

Reviewed By: arichardson

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

After vectorization, the exit blocks of the original loop will have additional
predecessors. Invalidate SCEVs for the exit phis in case SE looked through
single-entry phis.

Fixes https://github.com/llvm/llvm-project/issues/63368
Fixes https://github.com/llvm/llvm-project/issues/63669

ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
  return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
  Error(L, "msg");
  return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.

Reviewed By: asb

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

ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
  return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
  Error(L, "msg");
  return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.

Reviewed By: kosarev

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

ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
  return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
  Error(L, "msg");
  return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.

Reviewed By: xen0n

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

ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
  return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
  Error(L, "msg");
  return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.

Reviewed By: zixuan-wu

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

ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
  return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
  Error(L, "msg");
  return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.

Reviewed By: myhsu

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

Add td definitions and asm/disasm tests for the quantum adjustment
instructions in ISA 3.1 section 5.6.4

Reviewed By: stefanp

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

ParseStatus is slightly more convenient to use due to implicit
conversion from bool, which allows to do something like:
```
  return Error(L, "msg");
```
when with MatchOperandResultTy it had to be:
```
  Error(L, "msg");
  return MatchOperand_ParseFail;
```
It also has more appropriate name since parse* methods are not only for
parsing operands.

Reviewed By: kosarev

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

There are couple of optimizations of `__hash_table::find` which are applicable
to other places like `__hash_table::__node_insert_unique_prepare` and
`__hash_table::__emplace_unique_key_args`.

```
for (__nd = __nd->__next_; __nd != nullptr &&
    (__nd->__hash() == __hash
    // ^^^^^^^^^^^^^^^^^^^^^^
    //         (1)
      || std::__constrain_hash(__nd->__hash(), __bc) == __chash);
                                               __nd = __nd->__next_)
{
    if ((__nd->__hash() == __hash)
    // ^^^^^^^^^^^^^^^^^^^^^^^^^^
    //           (2)
        && key_eq()(__nd->__upcast()->__value_, __k))
        return iterator(__nd, this);
}
```

(1): We can avoid expensive modulo operations from `std::__constrain_hash` if
hashes matched. This one is from commit 6a411472.
(2): We can avoid `key_eq` calls if hashes didn't match. Commit:
318d35a7.

Both of them are applicable for insert and emplace methods.

Results of unordered_set_operations benchmark:
...

"&" seemed to be used in a situation where perhaps it's not the best option.
Other libc++ modules make use of [this] when calling functions from the same class.
[this] would be the appropriate lambda capture specifier to use in this situation.

Reviewed By: #libc, ldionne

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

Reviewed By: #libc, Mordante

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

With this patch error messages are improved. So far, error messages like
`operand #0 must An opaque type` can be generated.

Reviewed By: jpienaar

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

The filesystem clock implementation should be available regardless of
whether a proper filesystem is available on the platform, so it makes
sense to try and avoid including things that are inherently filesystem-y
in the implementation of filesystem clock.

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

This adds some basic handling in TargetTransformInfo to treat
vector_reduce_fminimum/vector_reduce_fmaximum similar to
vector_reduce_fmax/vector_reduce_fmax, getting better costs via
getMinMaxReductionCost.

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

Summary:
This function is intended to only be used on the GPU as a shorthand. The
static assert should only fire if it's called ,but it seems that its
precence can sometimes cause issues and other times not. Simply remove
it as it's causing build problems.

It's not a Check* function, so try to stay consistent and move this to
the header.