Codegen can handle XRay for AArch64, tell the driver to allow it.

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

Handle PT_GNU_RELRO segment in accordance with Linux Standard Base spec
chapter 12:

> PT_GNU_RELRO
> The array element specifies the location and size of a segment which may
> be made *read-only* after relocations have been processed.

Perform a readelf-style mapping check between this segment and sections,
set `IsRelro` section attribute.

Reviewed By: #bolt, maksfb

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

Codegen OS-agnostic for ELF and the runtime is mostly OS-agnostic. It
seems unnecessary to make restriction.

While here, rewrite test/Driver/XRay/xray-instrument*.c to be more conventional:
specify --target= explicitly instead of relying on the configured default target
(which needs `REQUIRES:`).

I am not sure enumerating every supported architecture is useful, so we just test a few.

This reverts commit 0d4ef4ff.

This was causing build failures on certain platforms when built with
-Werror due to unused variable warnings in addition to causing build
failures on Linux systems with older kernel versions as kernels prior to
v5.15 don't support sys_pidfd_getpid. Reverting as I need to setup a
system to properly test the rest of the patches in this series.

Also reverts 8c6668fa which fixed the
first issue so that the patch can actually be reverted.

/data/llvm-project/llvm/tools/llvm-exegesis/lib/BenchmarkRunner.cpp:275:9: error: unused variable 'ParentPIDFD' [-Werror,-Wunused-variable]
    int ParentPIDFD = syscall(SYS_pidfd_open, ParentPID, 0);
        ^
1 error generated.

This class has been causing me no end of grief for a long time, and the way it is used by mlir-tblgen is technically an ODR violation in certain situations.

Due to the way that the build is layered, it is important that the MLIR tablegen libraries only depend on the LLVM tablegen libraries, not on anything else (like MLIRSupport). It has to be this way because these libraries/binaries are special and must pre-exist the full shared libraries. Therefore, the dependency chain must be clean (and static).

At some point, someone pulled out a separate build target for just IndendedOstream in an attempt to satisfy the constraint. But because it is weird in different ways, this target was never installed properly as part of distributions, etc -- this causes problems for downstreams seeking to build a tblggen binary that doesn't itself have ODR/shared library problems.

I was attempting to fix the distribution stuff but just opted to collapse this into a header-only library and not try to solve this with build layering. I think this is the safest and the least bad thing for such a dep. This also makes for a clean comment that actually explains the constraint (which I was having trouble verbalizing with the weird subset dependency).

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

This patch introduces the subprocess executor mode. Currently, this new
mode doesn't do anything fancy, just executing the same code that the
inprocess executor would do, but within a subprocess. This sets up the
ability to add in many more memory-related features in the future.

Reviewed By: courbet

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

This avoids a regression when SignBitMustBeZero is moved to computeKnownFPClass.

This patch gives the ability to assign performance counters within
llvm-exegesis to a specific process by passing its PID. This is needed
later on for implementing a subprocess executor. Defaults to zero, the
current process, for the InProcessFunctionExecutorImpl.

Reviewed By: courbet

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

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

In order to better support adding in new implementations of
FunctionExecutor, this patch makes some small changes so that it is
easier to add new ones in. FunctionExecutorImpl is renamed to
InProcessFunctionExecutorImpl to better reflect how it will be placed
relative to the soon-to-be introduced subprocess executor and a new
function is created to create executors so selection can be done more
easily. In addition, a new CLI flag, -execution-mode, which can be used
to select between the different executors.

Reviewed By: courbet

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

When LLDB fails to pull file from a package directory due to security
constraint, user needs to set the package name to
'platform.plugin.remote-android.package-name' property to run shell commands
as the package user. (e.g. to get file with 'cat' and 'dd').

https://cs.android.com/android/platform/superproject/+/master:
system/core/run-as/run-as.cpp;l=39-61;
drc=4a77a84a55522a3b122f9c63ef0d0b8a6a131627

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

To test D152759 [lldb][Android] Support zip .so file

introduce PlatformAndroidTest with the capability of mocking adb client.

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

Reviewed By: K-Wu

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

The Objective-C runtime now stashes some state in TLS so any
test that indirectly initializes an Objective-C object will
have false positive leaks unless use_tls=1 as is the default.

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

llvm-objcopy should not insert padding before a section if its
physical addresses is not aligned to section's alignment. This
behavior will match GNU objcopy and is important for embedded images
where the physical address is used to store the initial data image.
The loader typically will copy this image using a start symbol
created by the linker. If llvm-objcopy inserts padding before such a
section, the symbol address will not match the location in the image.

This commit refines the change in https://reviews.llvm.org/D128961
which intended to align sections which type changed from NOBITS and
their offset may not be aligned. However, it affected all sections.

Fix https://github.com/llvm/llvm-project/issues/62636

Reviewed By: jhenderson, MaskRay

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

In Android API level 23 and above, dynamic loader is able to load .so file
directly from APK, which is zip file.
https://android.googlesource.com/platform/bionic/+/master/
android-changes-for-ndk-developers.md#
opening-shared-libraries-directly-from-an-apk

The .so file is page aligned and uncompressed, so
ObjectFileELF::GetModuleSpecifications works with .so file offset and size
directly from zip file without extracting it. (D152757)

GDBRemoteCommunicationServerCommon::GetModuleInfo returns a module spec to LLDB
with "zip_path!/so_path" file spec, which is passed through from Android
dynamic loader, and the .so file offset and size.

PlatformAndroid::DownloadModuleSlice uses 'shell dd' to download the .so file
slice from the zip file with the .so file offset and size.

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

Align YAML and fdata profiles by sorting CallSiteInfo targets by symbol name,
aligning it to fdata. By default, YAML CallSiteInfo is sorted by function id,
which is the order of function in the binary.

Follow-up to D152731, aligning yaml vs fdata, and in turn all three between to
each other.

Reviewed By: #bolt, rafauler

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

In Android API level 23 and above, dynamic loader is able to load .so file
directly from APK.
https://android.googlesource.com/platform/bionic/+/master/
android-changes-for-ndk-developers.md#
opening-shared-libraries-directly-from-an-apk

ObjectFileELF::GetModuleSpecifications will load a .so file, which is page
aligned and uncompressed, directly from a zip file. However it does not
set the .so file offset and size to the ModuleSpec. Also crc32 calculation
uses more data than the .so file size.

Set the .so file offset and size to the ModuleSpec, and set the size to
MapFileData length argument. For normal file, file_offset should be zero,
and length should be the size of the file.

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

This reverts commit eb1442d0.

The test tools/llvm-objcopy/ELF/binary-paddr.test fails on
ppc64be-clang-test-suite:
https://lab.llvm.org/buildbot#builders/231/builds/13120

Reverting at author's request.

These functions have been deprecated since:

  commit f271e5d9
  Author: Kazu Hirata <kazu@google.com>
  Date:   Sun Mar 12 18:25:07 2023 -0700

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

It looks like MLIR is using the more modern CMAKE_LIBRARY_OUTPUT_DIRECTORY, but AddLLVM still uses this older LLVM specific alias.

In the specific case I was running into, the empty variable was causing `-Wl,-rpath-link,` on the command line, causing the following argument to be swallowed. This was maddening, because the following argument was the .o file containing `main` and I was getting `main` undefined errors when it was clearly there. This is egregious enough that I chose to guard it.

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

- FileCheck variables for metadata are defined and referenced rather than
  repeatedly redefined.
- All numeric metadata identifiers are refactored to a FileCheck variable.

Reviewed By: MaskRay

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

This pass used to cause huge compile time regressions, That has been
address and can now be re-added.

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

llvm-objcopy should not insert padding before a section if its
physical addresses is not aligned to section's alignment. This
behavior will match GNU objcopy and is important for embedded images
where the physical address is used to store the initial data image.
The loader typically will copy this image using a start symbol
created by the linker. If llvm-objcopy inserts padding before such a
section, the symbol address will not match the location in the image.

This commit refines the change in https://reviews.llvm.org/D128961
which intended to align sections which type changed from NOBITS and
their offset may not be aligned. However, it affected all sections.

Fix https://github.com/llvm/llvm-project/issues/62636

Reviewed By: jhenderson, MaskRay

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

It's giving me trouble in an upcoming patch so I figured I'd do it as
a NFC before landing that other patch.

I'm adding llvm-profgen as an alternative AutoFDO profile generator to the user manual. llvm-profgen is widely used and tested by META as their default profile generator.

Reviewed By: davidxl

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

Currently the implementation of the RPC interface requires a flexible
struct. This caused problems when compilling the RPC server with GCC as
would be required if trying to export the RPC server interface. This
required that we either move to the `x[1]` workaround or make it a
template parameter. While just using `x[1]` would be much less noisy,
this is technically undefined behavior. For this reason I elected to use
templates.

The downside to using templates is that the server code must now be able
to handle multiple different types at runtime. I was unable to find a
good solution that didn't rely on type erasure so I simply branch off of
the given value.

Reviewed By: JonChesterfield

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

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

Fix #63413

This commit introduces the `irdl.attributes` operation, which allows defining named attributes for the parent operation. Each attribute is defined with a name and a type constraint.

Example usage:
```
irdl.dialect @example {
  irdl.operation @attr_op {
    %0 = irdl.any
    %1 = irdl.is i64
    irdl.attributes {
      "attr1" = %0,
      "attr2" = %1
    }
  }
}
```
In this example the operation will expect an arbitrary attribute "attr1"
and an attribute "attr2" with value `i64`.

Reviewed By: math-fehr, Mogball

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

This reverts commit 46c2e1fdb3065542bed96ba944ae4a58465d2b5e.

The fix was already landed in 51e917d4.

There are two ways to make symbols from a shared library visible in the
execution engine: exporting the symbols with public visibility or
implementing a loading/unloading mechansim that registers the exported
symbols explicitly. The latter has only been available in the JIT runner
until recently, but https://reviews.llvm.org/D153029 makes it available
in any usage of the execution engine (including the Python bindings).

This patch makes the runner utils library use the latter mechanism
instead of the former, i.e., it makes all of its symbols private and
implements the init/destroy functions of the loading mechanism to
control explicitly which symbols it registers.

Reviewed By: mehdi_amini

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

The async runtime library explicitly registers the symbols it exports
with the loading mechanism of the execution engine. This even works even
though these symbols were marked as hidden in the library. However, if
used outside the execution engine, such as with `lli --dlopen` or if AOT
compiled, these hidden symbols would not be found. This patch thus marks
all symbols that are part of the API as visible.

Reviewed By: mehdi_amini

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

ec146cb7 added two new ReducKinds for float maximum and minimum
(along with support in loop vectorizer).

Enumerate these kinds in SLPVectorizer to fix mlir windows build bot
errors:

C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Vectorize\SLPVectorizer.cpp(13883): error C2220: the following warning is treated as an error
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Vectorize\SLPVectorizer.cpp(13883): warning C4062: enumerator 'llvm::RecurKind::FMinimum' in switch of enum 'llvm::RecurKind' is not handled