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

default.

- Currently, the default instructions will use Clang's frontend PGO
  feature.

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

In particular, this ensures that it is used for Objective-C and
Objective-C++, since we have a few files that get detected as that.

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

Like for X86, some of the tests also need to be disabled for AArch64.

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

This patch:
(1) adds the add_with_carry_const and sub_with_borrow_const constexpr calls
to add and sub, respectively. Both add and sub are constexpr calls and
were call the non-constexpr version of add/sub_with_borrow.
(2) adds explicit UIntType construct calls in some fp tests.

Reviewed By: lntue

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

In this CL, we introduce two new locks, MMLock for MemMap operations and
FLLock for freelist operations.

MMLock will be used when we want to manipulate pages. For example,
mapping more pages through populateFreeList() and releaseToOSMaybe().

FLLock will be used when we want to access the freelist. For example,
pushBlocks() and popBatch().

With the new locks, they increase the parallelism of the operations
mentioned above. For example, populateFreeList() won't block the
pushBlocks() when it's still doing the system call for more pages.

We also enforce lock hierarchy to avoid deadlock, MMLock is required to
be held before FLLock if you have to lock both of them. We don't store
the lock owner, therefore, we rely static thread-safey annotation to
detect any violation.

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

D118754 added a new DICompileUnit::DebugNameTableKind for "Apple", so that,
under DWARF 5, the following combination is used inside DwarfDebug.cpp:

```
(lldb) p getAccelTableKind()
(llvm::AccelTableKind) $6 = Dwarf
(lldb) p CU.getNameTableKind()
(llvm::DICompileUnit::DebugNameTableKind) $7 = Apple
```

This creates a problem in the if statements changed, whereby "for non Apple
AccelTableKind" we emit empty tables for any DebugNameTableKind that is not
"Default". We should consider the newly added kind here too.

Note that our existing test could have caught this, if only it had checked the
_contents_ of the table, instead of merely checking for the existence of the
section.

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

This test uses a separate input file, so its IR is meaningless.

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

Depends on D151397.

This patch follows the patch-set of D151395. This patch seeks to
update all the remaining fixed-point intrinsics to model vxrm
control, adding rounding mode control for `vsmul`, `vssra`,
`vssrl`, `vnclip`, and `vnclipu`.

Reviewed By: craig.topper

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

Depends on D151396.

This is the 3rd patch of the patch-set. For the cover letter of the
patch-set, please checkout D151395.

This commit consists of change in both clang front-end and RISC-
back-end.

In the front-end, this commit adds an additional operand to the C
intrinsics of `vaadd`, `vaaddu`, `vasub`, and `vasubu`, that models
the control of the rounding mode.

In the back-end, using `vaadd` as an example, this commit replaces the
existing `int.riscv.vaadd.*` with `int.riscv.vaadd.rm.*` that was
introduced in the previous patch, with the extra operand that models
the control of the rounding mode (`vxrm`) for RVV fixed-point
intrinsics.

Note: The first 3 commit of the patch-set shows the intent to model the
rounding mode for fixed-point intrinsics by applying change to
`vaadd`, `vaaddu`, `vasub`, and `vasubu`. The proceeding patch will
apply the change to the rest of the other fixed-point instructions.

Reviewed By: craig.topper

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

[2/3][RISCV][POC] Model vxrm in LLVM intrinsics and machine instructions for RVV fixed-point instructions

Depends on D151395.

This is the 2nd patch of the patch-set. For the cover letter of the
patch-set, please checkout D151395. This patch originates from
D121376.

This commit models vxrm by adding an immediate operand into intrinsics
and machine instructions of RVV fixed-point instruction `vaadd`,
`vaaddu`, `vasub`, and `vasubu`. This commit only covers intrinsics of
the four instructions, the proceeding patches of the patch-set will do
the same to other RVV fixed-point instructions.

The current naiive approach is to have a write to vxrm inserted before
every fixed-point instruction. This is done by the new added pass
`RISCVInsertReadWriteCSR`. The reason to name the pass in a more general
term is because we will also model rounding mode for the RVV floating-
point instructions. The approach will be improved in the future,
implementing partial redundancy elimination algorithms to it.

The original LLVM intrinsics and machine instructions, take `vaadd` as
an example, does not model the rounding mode is not removed in this
patch. That is, `int.riscv.vaadd.*` co-exists with
`int.riscv.vaadd.rm.*` after this patch. The next patch will add C
intrinsics of vaadd with an additional operand that models the control
of the rounding mode, in this patch, `int.riscv.vaadd.rm.*` will
replace `int.riscv.vaadd.*`.

Authored-by: ShihPo Hung <shihpo.hung@sifive.com>
Co-Authored-by: eop Chen <eop.chen@sifive.com>

Reviewed By: craig.topper

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

Similar to operation handles, merging handles for other types can be useful to
avoid repetition of common transformations across a set of parameters.
For example, forming a list of static values for comparison rather than
comparing the parameters one at a time.

Reviewed By: ftynse

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

{min,max}imum(X, X) is X so we can take the same path as min/max.