This ensures these types have distinct names if they are distinct types
(eg: if one is an instantiation with a type in one inline namespace, and
another from a type with the same simple name, but in a different inline
namespace).

This patch doesn't support the optional operands of ImageDrefGather. The support of optional operands will be implemented later.

co-authered-by: Alan Liu <alanliu.yf@gmail.com>

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

This reverts commit e35afbe5, reapplying
022ccedd and
e7ed5c92.

- The first attempt missed defining `SignpostEmitterImpl`.
- The second attempt missed defining `llvm::SignpostEmitterImpl`.

Not sure how I failed to test both versions locally before; I thought
I'd turned the feature off via rerunning `cmake` but it must have been
stuck in place. This time I confirmed via `clang -E` that I was testing
both build configurations.

Original commit message:

    Replace some manual memory management with std::unique_ptr.

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

This reverts commit e7ed5c92 again, due
to more buildbot failures:
https://lab.llvm.org/buildbot/#/builders/131/builds/8191

This reverts commit 07807228, reapplying
022ccedd.

I figured out why this was failing in other environments: it's not a
problem with std::unique_ptr, but that SignpostEmitterImpl only has a
forward declaration. Adding an empty definition should do the trick.

Original commit message:

    Replace some manual memory management with std::unique_ptr.

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

This reverts commit 022ccedd. Looks like
some hosts need a definition of SignpostEmitterImpl to put it in a
unique_ptr:
https://lab.llvm.org/buildbot/#/builders/92/builds/7733

The destructor for SignPostEmitterImpl::SignpostLog is known statically. Avoid
the unnecessary vtable indirection through std::function in the std::unique_ptr
by turning LogDeleter into a struct. No real functionality change here.

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

This is a DenseMap, which has its own initializer; we don't need to explicitly
call the default constructor here.

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

Replace some manual memory management with std::unique_ptr.

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

Add a variant of `fs::resize_file` for use immediately before opening a
file with `mapped_file_region::readwrite`. On Windows, `_chsize`
(`ftruncate`) is slow, but `CreateFileMapping` (`mmap`) automatically
extends the file so the call to `fs::resize_file` can be skipped.

This optimization was added to `FileOutputBuffer` in
da9bc2e5; this commit just extracts the
logic out and adds a unit test.

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

Dialects can be translated to LLVM IR when they have the
LLVMTranslationDialectInterface interface registered. In case the
interface isn't explicitly registered, even the LLVM dialect can't be
exported to LLVM IR. This make the error message more explicit on this.

Reviewed By: ftynse

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

Required for capturing base specifier in matchers:
  `cxxRecordDecl(hasDirectBase(cxxBaseSpecifier().bind("base")))`

Reviewed By: steveire, aaron.ballman

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

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

[RISCV] Use multiclass inheritance where possible for the VPat* multiclasses in RISVInstrInfoVPseudos. NFCI

Instead of instantiating multiclasses inside multiclasses, just
inherit from them.

We can do the same for the VPseudo* multiclasses, but that may
interfere with the scheduler class work.

This doesn't do anything so it's just wasted characters. I have
other plans for the ones in multiclasses.

The test is failing on GreenDragon. Pinged Michał in D98822.

We should not re-try attempt of finding of the consecutive store chain
if it was tried before.

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

Pretty straightforward use of existing infrastructure and port of the attributor inference rules for nosync.

A couple points of interest:
* I deliberately switched from "monotonic or better" to "unordered or better". This is simply me being conservative and is better in line with the rest of the optimizer. We treat monotonic conservatively pretty much everywhere.
* The operand bundle test change is suspicious. It looks like we might have missed something here, but if so, it's an issue with the existing nofree inference as well. I'm going to take a closer look at that separately.
* I needed to keep the previous inference from readnone. This surprised me, but made sense once I realized readonly inference goes to lengths to reason about local vs non-local memory and that writes to local memory are okay. This is fine for the purpose of nosync, but would e.g. prevent us from inferring nofree from readnone - which is slightly surprising.

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

This fixes a "Cached first special instruction is wrong!" assert.

The assert fires because replacing a value with another can cause an
instruction to no longer be "special" to ICF. In this case,
devirtualization happened, turning an indirect call to a
call to a willreturn function which is no longer special.

Reviewed By: nikic, rnk

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

The motivation here is so we can run the compiler-rt tests
from a standalone build against AppleClang.

In particular the `Posix/halt_on_error-torture.cpp` and
`Posix/halt_on_error_suppress_equal_pcs.cpp` ASan test cases currently
require this binary for the tests to pass.

rdar://76366784

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

Proposed edit https://reviews.llvm.org/D97845#inline-922769 in D97845
suggests the checkWildcardRegexCharMatchFailure function name is
misleading because it is not clear it checks for a match failure on each
character in the string parameter. This commit renames it to an
hopefully clearer name.

Reviewed By: jdenny

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

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

It used to work correctly even with a KILL, but there is
no reason to consider meta instructions since they do not
create real HW uses.

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

When debugging LanguageRuntime unwindplans, it can be
helpful to disable their use and see the normal
stack walk.  Add a setting for this.

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

After D99249 we use three different loop pass managers for LICM,
LoopRotate and LICM+LoopUnswitch. This happens because LazyBFI
and LazyBPI are not preserved by LoopRotate (note that D74640
is no longer needed). Avoid this by marking them as preserved.

My understanding of D86156 is that it is okay to simply preserve
them (which LoopUnswitch already does for the same reason) and
rely on callbacks to deal with deleted blocks.

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

Fixes: SWDEV-274276

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

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

[flang][OpenMP] Add functionality to check "close nesting" of regions, which can be used for Semantic checks.  Also adding more test cases.

Reviewed By: kiranchandramohan

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

This patch unconditionally converts i1 types to i8 types on memrefs. If the
extensions or capabilities are not met, they will be converted to i32. Hence the
logic in IntLoadPattern and IntStorePattern are also updated.

Also added the implementation of SPIRVTypeConverter::getOptions().

Reviewed By: antiagainst

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

wasm64 was missing DAG ISEL patterns for external symbol based global.get, but simply adding these analogous to the existing 32-bit versions doesn't work.
This is because we are conflating the 32-bit global index with the pointer represented by the external symbol, which for wasm32 happened to work.
The simplest fix is to pretend we have a 64-bit global index. This sounds incorrect, but is immaterial since once this index is stored as a MachineOperand it becomes 64-bit anyway (and has been all along). As such, the EmitInstrWithCustomInserter based implementation I experimented with become a no-op and no further changes in the C++ code are required.

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

After loop interchange, the (old) outer loop header should not jump to
the `LoopExit`. Note that the old outer loop becomes the new inner loop
after interchange. If we branched to `LoopExit` then after interchange
we would jump directly from the (new) inner loop header to `LoopExit`
without executing the rest of outer loop.

This patch modifies adjustLoopBranches() such that the old outer
loop header (which becomes the new inner loop header) jumps to the
old inner loop latch which becomes the new outer loop latch after
interchange.

Reviewed By: bmahjour

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

Add InstAlias that allows the last operand to be an imm for following instructions:

1. Zbb or Zbp:
    - ror
    - rorw (RV64 Only)

2. Zbs
    - best
    - bclr
    - binv
    - bext

Reviewed By: craig.topper, jrtc27

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

The smax case shows up in https://llvm.org/PR49885 .
The others seem unlikely, but we might as well try
for uniformity (although that could mean an extra
instruction to create "nabs").

smax -- https://alive2.llvm.org/ce/z/8yYaGy
smin -- https://alive2.llvm.org/ce/z/0_7zc_
umax -- https://alive2.llvm.org/ce/z/EcsZWs
umin -- https://alive2.llvm.org/ce/z/Xw6WvB

The backend can't handle this and will throw a fatal error from
type legalization. It's easy enough to fix that for this intrinsic
by just splitting the IR intrinsic since it works on individual bytes.

There will be other intrinsics in the future that would be harder
to support through splitting, for example grev, gorc, and shfl. Those
would require a compare and a select be inserted to check the MSB of
their control input.

This patch adds support for preventing this in the frontend with
a nice diagnostic.

Reviewed By: frasercrmck

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

clang++ uses llvm.compiler.used in certain cases to preserve
symbol which is fully inlined. D96087 has resulted in undefined
symbols in such cases. Set it to false by default to preserve
old behavior but keep the option for specific uses where we
want to ignore these (e.g. to detect a potential indirect call
to a function).

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

Swift builds seem to use it. All it requires is emitting the
corresponding paths as STABS.

Fixes llvm.org/PR49385.

Reviewed By: clayborg

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