This reverts commit 3d0e9edd.

Breaking HWASAN buildbot:
https://lab.llvm.org/buildbot/#/builders/236/builds/786

Shown by targetted builds breaking at this patch:
Built at this patch: https://lab.llvm.org/buildbot/#/builders/236/builds/803
Built at prior patch: https://lab.llvm.org/buildbot/#/builders/236/builds/804

Reviewed By: wrengr, Peiming

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

Follow-up to 7846d590

Seen here:
https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/include/dwarf2.def#L805-L806

Currently pseudo probe encoding for a function is like:
	- For the first probe, a relocation from it to its physical position in the code body
	- For subsequent probes, an incremental offset from the current probe to the previous probe

The relocation could potentially cause relocation overflow during link time. I'm now replacing it with an offset from the first probe to the function start address.

A source function could be lowered into multiple binary functions due to outlining (e.g, coro-split). Since those binary function have independent link-time layout, to really avoid relocations from .pseudo_probe sections to .text sections, the offset to replace with should really be the offset from the probe's enclosing binary function, rather than from the entry of the source function. This requires some changes to previous section-based emission scheme which now switches to be function-based. The assembly form of pseudo probe directive is also changed correspondingly, i.e, reflecting the binary function name.

Most of the source functions end up with only one binary function. For those don't, a sentinel probe is emitted for each of the binary functions with a different name from the source. The sentinel probe indicates the binary function name to differentiate subsequent probes from the ones from a different binary function. For examples, given source function

```
Foo() {
  …
  Probe 1
  …
  Probe 2
}
```

If it is transformed into two binary functions:

```
Foo:
   …

Foo.outlined:
   …
```

The encoding for the two binary functions will be separate:

```

GUID of Foo
  Probe 1

GUID of Foo
  Sentinel probe of Foo.outlined
  Probe 2
```

Then probe1 will be decoded against binary `Foo`'s address, and Probe 2 will be decoded against `Foo.outlined`. The sentinel probe of `Foo.outlined` makes sure there's not accidental relocation from `Foo.outlined`'s probes to `Foo`'s entry address.

On the BOLT side, to be minimal intrusive, the pseudo probe re-encoding sticks with the old encoding format. This is fine since unlike linker, Bolt processes the pseudo probe section as a whole and it is free from relocation overflow issues.

The change is downwards compatible as long as there's no mixed use of the old encoding and the new encoding.

Reviewed By: wenlei, maksfb

Differential Revision: https://reviews.llvm.org/D135912
Differential Revision: https://reviews.llvm.org/D135914
Differential Revision: https://reviews.llvm.org/D136394

The path in vimrc was old, replace it with <path-to-this-file> to be
consistent with above.

debugserver parses the Mach-O header & load commands of
binaries; if it does this with a binary whose LC_BUILD
platform enum it does not recognize, it will currently crash.
This patch changes MachProcss::GetPlatformString to return
an optional platform string, and updates the callers to
do the right thing when this optional could not be
provided.

Differential Revision: https://reviews.llvm.org/D136719
rdar://100452994

These isTypeValid calls are redundant because the isDerivedFrom call performs the same checks.

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

Instead of using `std::index_sequence` with a helper function template to access
each element in the tuple, leverage `std::apply` from C++17 to do the heavy
lifting for us.

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

There's no reason to shrink a constant or simplify
an operand in 2 steps.

This matches what we currently do for 'add' (although that
seems like it should be altered to handle the commutative
case).

Reviewed By: nikic, jcranmer-intel

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

Summary:
The existing implementation of the personality for legacy IBM xlclang++ compiler generated code passes the address of exception object in r14 for the landing pad to retrieve with a call to __xlc_exception_handle(). This clobbers the content of r14 in user code (and potentially, when running cleanup actions, the address of another exception object being passed). This patch changes to use the stack slot reserved for compilers to pass the address. It has been confirmed that xlclang++-generated code does not use this slot.

Reviewed by: hubert.reinterpretcast, cebowleratibm

This patch adds a version of `parseSymbolName` and
`parseOptionalSymbolName` to AsmParser that don't take an attribute name
and attribute list.

Reviewed By: rriddle

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

In order to be passed as passed-object in the dynamic dispatch, the
polymorphic pointer entity are emboxed. In this process, the dynamic
type must be preserve and pass to fir.embox as the tdesc operand. This
patch introduce a new ExtendedValue that allow to carry over the
dynamic type when the value is unboxed.

Depends on D136820

Reviewed By: PeteSteinfeld

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

Lowering of allocate statement for polymoprhic pointers is a bit
different than for allocatables. A call to `PointerNullifyDerived`
runtime function is done instead of `AllocatableInitDerived`.

Reviewed By: PeteSteinfeld

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

The UnifyAliasedResourcePass is actually only necessary for
targeting Apple GPUs via MoltenVK, where we need to translate
SPIR-V into MSL. The translation has limitations--no support
of aliased resources. So introducing a control to disable
this pass if targeting other platforms.

Reviewed By: kuhar

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

Should improve compile time for analysis and vectorization.

Metric: SLP.NumVectorInstructions

Program                                                                                       SLP.NumVectorInstructions
test-suite :: External/SPEC/CINT2017speed/623.xalancbmk_s/623.xalancbmk_s.test  6380.00                   6378.00 -0.0%
test-suite :: External/SPEC/CINT2017rate/523.xalancbmk_r/523.xalancbmk_r.test   6380.00                   6378.00 -0.0%
test-suite :: External/SPEC/CINT2006/483.xalancbmk/483.xalancbmk.test           2023.00                   2022.00 -0.0%
test-suite :: External/SPEC/CINT2006/471.omnetpp/471.omnetpp.test               148.00                    146.00 -1.4%

Generated more vector instructions.

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

This patch adds the assembly/disassembly for the following instructions:

pext (predicate) : Set predicate from predicate-as-counter
ptrue (predicate-as-counter) : Initialise predicate-as-counter to all active

This patch also introduces the predicate-as-counter registers pn8, etc.

The reference can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09

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

This prepare a subsequent revision that will generalize
the insertion code generation. Similar to the support lib,
insertions become much easier to perform with some "cursor"
bookkeeping. Note that we, in the long run, could perhaps
avoid storing the "cursor" permanently and use some
retricted-scope solution (alloca?) instead. However,
that puts harder restrictions on insertion-chain operations,
so for now we follow the more straightforward approach.

Reviewed By: Peiming

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

This patch adds a new infrastructure for OpenMP target plugins. It also implements the CUDA and GenericELF64bit plugins under this new infrastructure. We place the sources in a separate directory named plugins-nextgen, and we build the new plugins as different plugin libraries. The original plugins, which remain untouched, will be used by default. However, the user can change this behavior at run-time through the boolean envar LIBOMPTARGET_NEXTGEN_PLUGINS. If enabled, the libomptarget will try to load the NextGen version of each plugin, falling back to the original if they are not present or valid.

The idea of this new plugin infrastructure is to implement the common parts of target plugins in generic classes (defined in files inside plugins-next/common/PluginInterface folder), and then, each specific plugin defines its own specific classes inheriting from the common ones. In this way, most logic remains on the common interface while reducing the plugin-specific source code. It is also beneficial in the sense that now most code and behavior are the same across the different plugins. As an example, we define classes for a plugin, a device, a device image, a stream manager, etc. The plugin object (a single instance per plugin library) holds different device objects (i.e., one per available device), while these latter are the responsible for managing its own resources.

Most code on this patch is based on the changes made by @jdoerfert (Johannes Doerfert)

Reviewed By: jhuber6, jdoerfert

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

The -fstrict-flex-arrays=3 is the most restrictive type of flex arrays.
No number, including 0, is allowed in the FAM. In the cases where a "0"
is used, the resulting size is the same as if a zero-sized object were
substituted.

This is needed for proper _FORTIFY_SOURCE coverage in the Linux kernel,
among other reasons. So while the only reason for specifying a
zero-length array at the end of a structure is for specify a FAM,
treating it as such will cause _FORTIFY_SOURCE not to work correctly;
__builtin_object_size will report -1 instead of 0 for a destination
buffer size to keep any kernel internals from using the deprecated
members as fake FAMs.

For example:

  struct broken {
      int foo;
      int fake_fam[0];
      struct something oops;
  };

There have been bugs where the above struct was created because "oops"
was added after "fake_fam" by someone not realizing. Under
__FORTIFY_SOURCE, doing:

  memcpy(p->fake_fam, src, len);

raises no warnings when __builtin_object_size(p->fake_fam, 1) returns -1
and may stomp on "oops."

Omitting a warning when using the (invalid) zero-length array is how GCC
treats -fstrict-flex-arrays=3. A warning in that situation is likely an
irritant, because requesting this option level is explicitly requesting
this behavior.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

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

Reviewed By: aartbik

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

This adds a new function for creating pass managers that takes an
argument for the anchor string.

Reviewed By: mehdi_amini

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

DXContainer files contain a part that has an MD5 of the generated
shader. This adds support to the ObjectYAML tooling to expand the hash
part data and hash iteself in preparation for adding hashing support to
DirectX code generation.

Reviewed By: python3kgae

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

This adds the fgets function and its unit tests.

Reviewed By: sivachandra

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

The LSR may suggest less profitable transformation to the loop. This
patch adds check to prevent LSR from generating worse code than what
we already have.

Since LSR affects nearly all targets, the patch is guarded by the
option 'lsr-drop-solution' and default as disable for now.

The next step should be extending an TTI interface to allow target(s)
to enable this enhancememnt.

Debug log is added to remind user of such choice to skip the LSR
solution.

Reviewed By: Meinersbur, #loopoptwg

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

Currently any errors during pipeline parsing are reported to stderr.
This adds a new pipeline parsing function to the C api that reports
errors through a callback, and updates the python bindings to use it.

Reviewed By: mehdi_amini

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

readelf --section-details displays ch_type/ch_size/ch_addralign for
a SHF_COMPRESSED section. Port the feature. There is a small difference
that readelf doesn't display `[<corrupt>]` for an empty section while
we do.

Reviewed By: jhenderson

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

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

https://reviews.llvm.org/D136806

Reviewed By: RKSimon

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

It splited into several zb* extensions, and `b` is dropped after
0.93, so it time to retired that as other non-ratified zb* extensions.

Currntly clang can accept that with warning:

$ clang -target riscv64-elf ~/hello.c -S  -march=rv64gcb
'+b' is not a recognized feature for this target (ignoring feature)
'+b' is not a recognized feature for this target (ignoring feature)
'+b' is not a recognized feature for this target (ignoring feature)

Reviewed By: asb, luismarques

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