Replace the legacy legalizer versions

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

An empty structure in C has no way to be initialized, so triggering a
-Wuninitialized warning for a variable of empty structure type is not
actionable for users. This silences the false positive warning, which
matches the behavior of GCC as well.

We no longer diagnose if the structure has no members, or has only
zero-sized members (unnamed bit-fields, zero-sized bit-fields, empty
structure types).

Fixes: https://github.com/llvm/llvm-project/issues/26842

Add a CallVirt opcode and implement virtual function calls this way.

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

Provide direct access to v_exp_f32 and v_exp_f16, so we can start
correctly lowering the generic exp intrinsics.

Unfortunately have to break from the usual naming convention of
matching the instruction name and stripping the v_ prefix. exp is
already taken by the export intrinsic. On the clang builtin side, we
have a choice of maintaining the convention to the instruction name,
or following the intrinsic name.

This patch swaps out the `void *` behind `CXFile` from `FileEntry *` to `FileEntryRef::MapEntry *`. This allows us to remove some deprecated uses of `FileEntry::getName()`.

Depends on D151854.

Reviewed By: benlangmuir

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

[flang][OpenMP][OpenACC] Support stop statement in OpenMP/OpenACC region

This supports lowering of stop statement in OpenMP/OpenACC region.
* OpenMP/OpenACC: Emit `fir.unreachable` only if the block is not
  terminated by any terminator. This avoids knocking off an existing
  OpenMP/OpenACC terminator.
* OpenMP: Emit the OpenMP terminator instead of `fir.unreachable` since
  OpenMP regions can only be terminated by OpenMP terminators. This is
  currently skipped for OpenACC since unstructured code is not yet
  handled specially in OpenACC lowering.

Fixes #60737
Fixes #61877

Co-authored-by: Kiran Chandramohan <kiranchandramohan@gmail.com>
Co-authored-by: Val Donaldson <vdonaldson@nvidia.com>

Reviewed By: vdonaldson, peixin

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

When possible, use `OperationPass<>` instead of `OperationPass<ModuleOp>` or `OperationPass<FuncOp>`.

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

This finally officially deprecates `DirectoryEntry::getName()`. I checked no usages remain in targets built by any of `check-clang`, `check-clang-tools`, `check-clang-extra`. There are probably some remaining usages in places like LLDB and other clients. This will give them a chance to transition to `DirectoryEntryRef::getName()` before we remove the function altogether.

Depends on D151922.

Reviewed By: benlangmuir

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

The test added in 1665cb06 requires the X86 backend, so move it to
the X86 subdirectory.

Part of <https://github.com/llvm/llvm-project/issues/62629>.

Reviewed By: arsenm

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

Reviewed By: arsenm

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

Reviewed By: Joe_Nash

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

Reviewed By: Joe_Nash

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

Reviewed By: Joe_Nash

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

Reviewed By: Joe_Nash

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

Reviewed By: arsenm

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

This patch removes the last use of deprecated `DirectoryEntry::getName()`.

Depends on D151855.

Reviewed By: benlangmuir

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

This patch removes some deprecated uses of `{File,Directory}Entry::getName()`. No functional change intended.

Depends on D151854.

Reviewed By: benlangmuir

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

The greedy pattern rewrite driver removes ops that are "trivially dead". This could include symbols that are still referenced by other ops. Dead symbols should be removed with the `-symbol-dce` pass instead.

This bug was not triggered for `func::FuncOp`, because ops are not considered "trivally dead" if they do not implement the `MemoryEffectOpInterface`, indicating that the op may or may not have side effects. It is, however, triggered for `transform::NamedSequenceOp`, which implements that interface because it is required for all transform dialect ops.

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

Replace the legacy legalizer versions - interestingly the only concat_vectors isel patterns we currently have are for AVX512 predicate masks, which gisel doesn't handle at all yet.

Tests from #38847, #62852.

RuntimeDyld has been deprecated in favor of JITLink. [1] This patch
replaces all uses of RuntimeDyld in BOLT with JITLink.

Care has been taken to minimize the impact on the code structure in
order to ease the inspection of this (rather large) changeset. Since
BOLT relied on the RuntimeDyld API in multiple places, this wasn't
always possible though and I'll explain the changes in code structure
first.

Design note: BOLT uses a JIT linker to perform what essentially is
static linking. No linked code is ever executed; the result of linking
is simply written back to an executable file. For this reason, I
restricted myself to the use of the core JITLink library and avoided ORC
as much as possible.

RuntimeDyld contains methods for loading objects (loadObject) and symbol
lookup (getSymbol). Since JITLink doesn't provide a class with a similar
interface, the BOLTLinker abstract class was added to implement it. It
was added to Core since both the Rewrite and RuntimeLibs libraries make
use of it. Wherever a RuntimeDyld object was used before, it was
replaced with a BOLTLinker object.

There is one major difference between the RuntimeDyld and BOLTLinker
interfaces: in JITLink, section allocation and the application of fixups
(relocation) happens in a single call (jitlink::link). That is, there is
no separate method like finalizeWithMemoryManagerLocking in RuntimeDyld.
BOLT used to remap sections between allocating (loadObject) and linking
them (finalizeWithMemoryManagerLocking). This doesn't work anymore with
JITLink. Instead, BOLTLinker::loadObject accepts a callback that is
called before fixups are applied which is used to remap sections.

The actual implementation of the BOLTLinker interface lives in the
JITLinkLinker class in the Rewrite library. It's the only part of the
BOLT code that should directly interact with the JITLink API.

For loading object, JITLinkLinker first creates a LinkGraph
(jitlink::createLinkGraphFromObject) and then links it (jitlink::link).
For the latter, it uses a custom JITLinkContext with the following
properties:
- Use BOLT's ExecutableFileMemoryManager. This one was updated to
  implement the JITLinkMemoryManager interface. Since BOLT never
  executes code, its finalization step is a no-op.
- Pass config: don't use the default target passes since they modify
  DWARF sections in a way that seems incompatible with BOLT. Also run a
  custom pre-prune pass that makes sure sections without symbols are not
  pruned by JITLink.
- Implement symbol lookup. This used to be implemented by
  BOLTSymbolResolver.
- Call the section mapper callback before the final linking step.
- Copy symbol values when the LinkGraph is resolved. Symbols are stored
  inside JITLinkLinker to ensure that later objects (i.e.,
  instrumentation libraries) can find them. This functionality used to
  be provided by RuntimeDyld but I did not find a way to use JITLink
  directly for this.

Some more minor points of interest:
- BinarySection::SectionID: JITLink doesn't have something equivalent to
  RuntimeDyld's Section IDs. Instead, sections can only be referred to
  by name. Hence, SectionID was updated to a string.
- There seem to be no tests for Mach-O. I've tested a small hello-world
  style binary but not more than that.
- On Mach-O, JITLink "normalizes" section names to include the segment
  name. I had to parse the section name back from this manually which
  feels slightly hacky.

[1] https://reviews.llvm.org/D145686#4222642

Reviewed By: rafauler

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

The new pattern will replace elementwise(broadcast) with
broadcast(elementwise) when safe.

This change affects tests for vectorising nD-extract. In one case
("vectorize_nd_tensor_extract_with_tensor_extract") I just trimmed the
test and only preserved the key parts (scalar and contiguous load from
the original Op). We could do the same with some other tests if that
helps maintainability.

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

Reviewed By: Joe_Nash

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

rdar://108818859

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

Thanks to Zhang on Discord for spotting this.

This patch-set wants to model rounding mode for the fixed-point
intrinsics of the RVV C intrinsics.

The specification PR: [riscv-non-isa/rvv-intrinsic-doc#222](https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222)

The 3 patches is a proof-of-concept with a bottom-up approach
Going from machine instruction to LLVM intrinsics, then to the C
intrinsics. The 3 patches applies the rounding mode control on the
`vaadd` instruction. Proceeding patches will extend the change to all
other fixed-point computations.

---

This is the 1st commit of the patch-set.  This patch gives a name to
the machine instruction that writes an immediate into the CSR `vxrm`.

Reviewed By: craig.topper

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

AArch64 has five system registers intended to be useful as thread
pointers: one for each exception level which is RW at that level and
inaccessible to lower ones, and the special TPIDRRO_EL0 which is
readable but not writable at EL0. AArch32 has three, corresponding to
the AArch64 ones that aren't specific to EL2 or EL3.

Currently clang supports only a subset of these registers, and not
even a consistent subset between AArch64 and AArch32:

 - For AArch64, clang permits you to choose between the four TPIDR_ELn
   thread registers, but not the fifth one, TPIDRRO_EL0.

 - In AArch32, on the other hand, the //only// thread register you can
   choose (apart from 'none, use a function call') is TPIDRURO, which
   corresponds to (the bottom 32 bits of) AArch64's TPIDRRO_EL0.

So there is no thread register that you can currently use in both
targets!

For custom and bare-metal purposes, users might very reasonably want
to use any of these thread registers. There's no reason they shouldn't
all be supported as options, even if the default choices follow
existing practice on typical operating systems.

This commit extends the range of values acceptable to the `-mtp=`
clang option, so that you can specify any of these registers by (the
lower-case version of) their official names in the ArmARM:

 - For AArch64: tpidr_el0, tpidrro_el0, tpidr_el1, tpidr_el2, tpidr_el3
 - For AArch32: tpidrurw, tpidruro, tpidrprw

All existing values of the option are still supported and behave the
same as before. Defaults are also unchanged. No command line that
worked already should change behaviour as a result of this.

The new values for the `-mtp=` option have been agreed with Arm's gcc
developers (although I don't know whether they plan to implement them
in the near future).

Reviewed By: nickdesaulniers

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

Commit de0707a2 updated the check lines, but
due to conflicting assembly not all functions kept their checks. This now
distinguishes between selection-dag and global isel.

Instcombine will canonicalize `select(c, binop(a, b), a)` to
`binop(select(c, b, identityvalue), a)`. The original select form
makes a more natural form for vector predicated operations for
vector architectures like SVE where predication is well supported.
This patch enables shouldFoldSelectWithIdentityConstant for SVE so
that more predicated instructions can be generated, helping simplify
the handling with identity constants.

Predicated FMA patterns have also been adjusted here as they need to
look at FMF's. Other operations like add/sub, mul, and/or/xor and
mla/mls have been recently updated.

There is one test (scalable_int_min_max) that increases in size. There
are multiple selects that could be combined into a single select but
does not currently fold.

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

This fixes one of those 'Request for a fixed element count on a scalable
object' errors in the AArch64 isExtFreeImpl method, where the uses of a sext
are checked to see if the instruction can be considered free.
https://godbolt.org/z/debYP9c4G

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