There's no need to check for reference invalidation when
`SmallVector::resize` is shrinking; the parameter isn't accessed.

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

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

D91497 changed lldb/test/Shell/Register/x86-fp-write.test and added target-x86_64 to the REQUIRES clause.
It looks this test does not pass on this platform so removing it since it one of tests failing on the
green dragon build bot.

This is a mass-market version of the "dump AST" tweak we have behind
-hidden-features.
I think in this friendlier form it'll be useful for people outside clang
developers, which would justify making it a real feature.
It could be useful as a step towards lightweight clang-AST tooling in clangd
itself (like matcher-based search).

Advantages over the tweak:
 - simplified information makes it more accessible, likely somewhat useful
   without learning too much clang internals
 - can be shown in a tree view
 - structured information gives some options for presentation (e.g.
   icon + two text colors + tooltip in vscode)
 - clickable nodes jump to the corresponding code
Disadvantages:
 - a bunch of code to handle different node types
 - likely missing some important info vs dump-ast due to brevity/oversight
 - may end up chasing/maintaining support for the long tail of nodes

Demo with VSCode support: https://imgur.com/a/6gKfyIV

Differential Revi...

We need an AA pipeline under NPM.
This is a no-op if we are still using the legacy PM.

This patch decomposes `GEP %x, %offset` as  0 + 1 * %x + 1 * %off.

Just '-O2' didn't run the full AA pipeline under NPM.

Already has a NPM RUN line

This add missing updates to the header file that caused linking issues.
Original change at https://reviews.llvm.org/D91740

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

Unused since https://reviews.llvm.org/D91762 and triggering
-Wunused-private-field

```
llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp:365:13: error: private field 'GetArgTLS' is not used [-Werror,-Wunused-private-field]
  Constant *GetArgTLS;
            ^
llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp:366:13: error: private field 'GetRetvalTLS' is not used [-Werror,-Wunused-private-field]
  Constant *GetRetvalTLS;
```

Reviewed By: stephan.yichao.zhao

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

[InstCombine] Fold `and(shl(zext(x), width(SIGNMASK) - width(%x)), SIGNMASK)` to `and(sext(%x), SIGNMASK)`

One less instruction and reducing use count of zext.
As alive2 confirms, we're fine with all the weird combinations of
undef elts in constants, but unless the shift amount was undef
for a lane, we must sanitize undef mask to zero, since sign bits
are no longer zeros.

https://rise4fun.com/Alive/d7r
```
----------------------------------------
Optimization: zz
Precondition: ((C1 == (width(%r) - width(%x))) && isSignBit(C2))
  %o0 = zext %x
  %o1 = shl %o0, C1
  %r = and %o1, C2
=>
  %n0 = sext %x
  %r = and %n0, C2

Done: 2016
Optimization is correct!
```

Followup to 7de7c408. I previously
removed a number of == comparisons to LocationSize::unknown(), but
missed these != comparisons.

Null types are commonly used as an error marker. Catch them in the constructor
of Operation if they are present in the result type list, as otherwise this
could lead to further surprising behavior when querying op result types.

Fix AsyncToLLVM and StandardToLLVM that were using null types when constructing
operations.

Reviewed By: rriddle

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

clean more deadcode after D84704

Reviewed-by: morehouse

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

These utilities are more closely associated with the buffer
optimizations and buffer deallocation than with the dialect conversion
stuff in Bufferize.h. So move them out.

This makes Bufferize.h very easy to understand and completely focused on
dialect conversion.

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

Instead of comparing to LocationSize::unknown(), prefer calling
the hasValue() method instead, which is less reliant on
implementation details.

Followup to 393b9e9d,
where I missed updating one MemoryLocation use inside a unit test.

When constructing a MemoryLocation by hand, require that a
LocationSize is explicitly specified. D91649 will split up
LocationSize::unknown() into two different states, and callers
should make an explicit choice regarding the kind of MemoryLocation
they want to have.

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

UnionTableAddr is always inlined.

Reviewed-by: morehouse

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

Similarly to assumes and guards deoptimize intrinsics are
marked as writing to ensure proper control dependencies
but they never modify any particular memory location.

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

These pointers do not need to be mutable. This has an affect that generated function signatures in the Swift bindings now use `UnsafePointer` instead of `UnsafeMutablePointer`.

Reviewed By: ftynse, mehdi_amini

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

Instead of separately passing pointer and size, make use of
MemoryLocation. This allows us to also reuse all the existing
logic for determining the MemoryLocation correponding to an
instruction or call argument.

Not quite NFC because used locations may be more precise in some
cases.

Avoid MemoryLocation::UnknownSize when we're initializing a
LocationSize.

This moves handling of alwaysinline, coroutines, matrix lowering, PGO,
and LTO-required passes into PassBuilder. Much of this is replicated
between Clang and opt. Other out-of-tree users also replicate some of
this, such as Rust [1] replicating the alwaysinline, LTO, and PGO
passes.

The LTO passes are also now run in
build(Thin)LTOPreLinkDefaultPipeline() since they are semantically
required for (Thin)LTO.

[1]: https://github.com/rust-lang/rust/blob/f5230fbf76bafd86ee4376a0e26e551df8d17fec/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L896

Reviewed By: tejohnson

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

In the current state, if getFromHash(0) is called and there's no CU with
dwo_id=0, the lookup will stop at an empty slot, then the check
`Rows[H].getSignature() != S` won't cause the lookup to fail and return
a nullptr (as it should), because the empty slot has a 0 in the
signature field, and a pointer to the empty slot will be incorrectly
returned.

This patch fixes this by using the index field in the hash entry to
check for empty slots: signature = 0 can match a valid hash but
according to the spec the index for an occupied slot will always be
non-zero.

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

* Move ops to a BuiltinOps.h
* Add file comments

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

Patch by tlwilmar (Terry Wilmarth)

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

Standard libc++ headers in stdc++ mode include <new> which picks up
cuda_wrappers/new before any of the CUDA macros have been defined.

We can not include CUDA headers that early, so the work-around is to define
__device__ in the wrapper header itself.

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

Generate passes.h before trying to use it

Reviewed By: mehdi_amini

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

The `dso_local_equivalent` constant is a wrapper for functions that represents a
value which is functionally equivalent to the global passed to this. That is, if
this accepts a function, calling this constant should have the same effects as
calling the function directly. This could be a direct reference to the function,
the `@plt` modifier on X86/AArch64, a thunk, or anything that's equivalent to the
resolved function as a call target.

When lowered, the returned address must have a constant offset at link time from
some other symbol defined within the same binary. The address of this value is
also insignificant. The name is leveraged from `dso_local` where use of a function
or variable is resolved to a symbol in the same linkage unit.

In this patch:
- Addition of `dso_local_equivalent` and handling it
- Update Constant::needsRelocation() to strip constant inbound GEPs and take
  advantage of `dso_local_equivalent` for relative references

This is useful for the [Relative VTables C++ ABI](https://reviews.llvm.org/D72959)
which makes vtables readonly. This works by replacing the dynamic relocations for
function pointers in them with static relocations that represent the offset between
the vtable and virtual functions. If a function is externally defined,
`dso_local_equivalent` can be used as a generic wrapper for the function to still
allow for this static offset calculation to be done.

See [RFC](http://lists.llvm.org/pipermail/llvm-dev/2020-August/144469.html) for more details.

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

This commit does the renaming mentioned in the title in order to bring
'spv' dialect closer to the MLIR naming conventions.

Reviewed By: antiagainst

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