The trap value used by BOLT was assumed to be single-byte instruction.
It made some functions unaligned on AArch64(e.g exceptions-instrumentation test)
and caused emission failures. Fix that by changing fill value to StringRef.

Reviewed By: rafauler

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

Previously the --path-equivalence parameter would allow to specify a single remap pair (coverage data path - local source file path). This patch changes this allowing to pass as many remaps as needed.

Reviewed By: keith

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

When we add an assumption about memory to the AAPointerInfo bins, we
should simplify the assumed value, like we do for stores.

We are having a hard time optimizing some vectorized loads/stores later
on which causes this optimization to degrade performance.

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

the CI failure (https://green.lab.llvm.org/green/job/clang-san-iossim/) is being investigated using
this issue: https://github.com/llvm/llvm-project/issues/64942 .

rdar://113765281

This reverts commit f24aa691.

This change caused these two test failures on Darwin CI:
Clang.Tooling.clang-check-mac-libcxx-abspath.cpp
Clang.Tooling.clang-check-mac-libcxx-relpath.cpp

https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/37169/

More info in https://reviews.llvm.org/D157283

When matching FNEG patterns for the MachineCombiner we need to check for
opcodes first, before trying to extract a register from an operand.
Otherwise handling of instructions with non-register operands causes the
compiler to crash.

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

Some callers pass in an empty mask to represent "unknown".  We should use the generic costs for these cases.  We can add VL=1 costing seperately if desired.

Reapplying after revert.  A new test had been added, and I'd missed updating it when rebasing before.  This is a great happy accident as I hadn't figured out how to get SLP to exercise this case, I'd merely noticed it via inspection.

Previously this was based on target architecture, but
that makes very little sense--frame API availability is generally
for libgcc compatibility and that is dependent on runtime
needs rather than target architecture.

Default this to on, so as not to remove the apis from
environments that already have them.

The functions this macro protects are stubs for libgcc-compatibility.
Today, libunwind as a drop-in replacement for libgcc_eh links on x86,
x86_64, and powerpc, but not aarch64, which doesn't really make
sense. As there is nothing architecture specific about these, they
should be provided everywhere or nowhere.

The target-specific protection goes all the way back to the original
code contribution in 312fcd0e from
2013, so the original reason is lost to history, and probably not
relevant today.

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

Should fix error in https://lab.llvm.org/buildbot/#/builders/84/builds/41540.

This reverts commit 2246700e.  Seeing buildbot failures; it looks like I rebased over a new test which is effected by the change.

By using bootstrap symbols to communicate these addresseses, rather than dlsym
lookups, we no longer need them to be exported from the main executable. On ELF,
where symbols aren't exported from the main executable by default, this
eliminates a common source of missing symbol errors and allows for smaller
executables (if exports from the main executable aren't otherwise needed and
can be removed).

Although we already have fold-and-shift-x86_64.ll - this adds additional test coverage for various and-shift patterns split by sign/zero extensions from i32 index patterns to i64 pointers

Some callers pass in an empty mask to represent "unknown".  We should use the generic costs for these cases.  We can add VL=1 costing seperately if desired.

Lower the acc set directive to the acc.set op.

Depends on D158554

Reviewed By: razvanlupusoru

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

Move the code which sets CMake variables for MIPS to
compiler-rt/cmake/base-config-ix.cmake from compiler-rt/CMakeLists.txt.

compiler-rt/CMakeLists.txt includes compiler-rt/cmake/base-config-ix.cmake
very early. If the variables are set in compiler/CMakeLists.txt,
compiler-rt/cmake/base-config-ix.cmake cannot use them.

Reviewed By: MaskRay

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

This matches the check done by the Reassociate pass that we're
trying to reverse.

Reviewed By: nikic

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

This logic from 866faab4 (2012) is no
longer needed after D45233 added "Try to match the exact target triple first."

Reviewed By: rafauler

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

Because indirect call tables use static addresses for call sites, but pc
values recorded by runtime may be subject to ASLR in PIE, we couldn't
find indirect call descriptions by their runtime address in PIE. It
resulted in [unknown] entries in profile for all indirect calls. We need
to substract base address of .text from runtime addresses to get the
corresponding static addresses. Here we create a getter for base address
of .text and substract it's return value from recorded PC values. It
converts them to static addresses, which then may be used to find the
corresponding indirect call descriptions.

Reviewed By: rafauler

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

When a binary is instrumented with --instrumentation-sleep-time and
instrumentation-wait-forks options and lauched, the profile is
periodically written until all the forks die. The problem is that we
cannot wait for the whole process tree, and we have no way to tell when
it's safe to read the profile. Hovewer, if we keep profile open
throughout the life of the process tree, we can use fuser to determine
when writing is finished.

Reviewed By: rafauler

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

Split off mask creation for tail folding and proactively create the mask for
the header block.

This simplifies createBlockInMask.

Reviewed By: Ayal

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

We will migrate to a cleaner and more complete implementation.

Reviewed By: aartbik

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

This patch fixes https://github.com/llvm/llvm-project/issues/64935.

Reviewed By: craig.topper

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

This PR implements python enum bindings for *all* the enums - this includes `I*Attrs` (including positional/bit) and `Dialect/EnumAttr`.

There are a few parts to this:

1. CMake: a small addition to `declare_mlir_dialect_python_bindings` and `declare_mlir_dialect_extension_python_bindings` to generate the enum, a boolean arg `GEN_ENUM_BINDINGS` to make it opt-in (even though it works for basically all of the dialects), and an optional `GEN_ENUM_BINDINGS_TD_FILE` for handling corner cases.
2. EnumPythonBindingGen.cpp: there are two weedy aspects here that took investigation:
    1. If an enum attribute is not a `Dialect/EnumAttr` then the `EnumAttrInfo` record is canonical, as far as both the cases of the enum **and the `AttrDefName`**. On the otherhand, if an enum is a `Dialect/EnumAttr` then the `EnumAttr` record has the correct `AttrDefName` ("load bearing", i.e., populates `ods.ir.AttributeBuilder('<NAME>')`) but its `enum` field contains the cases, which is an instance of `EnumAttrInfo`. The solution is to generate an one enum class for both `Dialect/EnumAttr` and "independent" `EnumAttrInfo` but to make that class interopable with two builder registrations that both do the right thing (see next sub-bullet).
    2. Because we don't have a good connection to cpp `EnumAttr`, i.e., only the `enum class` getters are exposed (like `DimensionAttr::get(Dimension value)`), we have to resort to parsing e.g., `Attribute.parse(f'#gpu<dim {x}>')`. This means that the set of supported `assemblyFormat`s (for the enum) is fixed at compile of MLIR (currently 2, the only 2 I saw). There might be some things that could be done here but they would require quite a bit more C API work to support generically (e.g., casting ints to enum cases and binding all the getters or going generically through the `symbolize*` methods, like `symbolizeDimension(uint32_t)` or `symbolizeDimension(StringRef)`).

A few small changes:

1. In addition, since this patch registers default builders for attributes where people might've had their own builders already written, I added a `replace` param to `AttributeBuilder.insert` (`False` by default).
2. `makePythonEnumCaseName` can't handle all the different ways in which people write their enum cases, e.g., `llvm.CConv.Intel_OCL_BI`, which gets turned into `INTEL_O_C_L_B_I` (because `llvm::convertToSnakeFromCamelCase` doesn't look for runs of caps). So I dropped it. On the otherhand regularization does need to done because some enums have `None` as a case (and others might have other python keywords).
3. I turned on `llvm` dialect generation here in order to test `nvvm.WGMMAScaleIn`, which is an enum with [[ https://github.com/llvm/llvm-project/blob/d7e26b56207cbd8995296c5bb7c11ce676b649da/mlir/include/mlir/IR/EnumAttr.td#L22-L25 | no explicit discriminator ]] for the `neg` case.

Note, dialects that didn't get a `GEN_ENUM_BINDINGS` don't have any enums to generate.

Let me know if I should add more tests (the three trivial ones I added exercise both the supported `assemblyFormat`s and `replace=True`).

Reviewed By: stellaraccident

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

These symbols are used in the absence of PT_GNU_EH_FRAME, for ld
--no-eh-frame-hdr (gcc -static default).

libunwind defines these empty functions when
`defined(_LIBUNWIND_BUILD_ZERO_COST_APIS) && defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND) && defined(_LIBUNWIND_SUPPORT_FRAME_APIS)`.
They should be perceived as Mac OS X workarounds.

For Linux, GCC crtbeginT.o (for -static) and clang_rt.crtbegin.o contain
weak references to `__{,de}register_frame_info`. Dynamically linked
executables will either not reference `__{,de}register_frame_info` (using
libgcc) or reference them as weak symbols (using compiler-rt).

Therefore, not defining these symbols is backward compatible.

Reviewed By: phosek

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

Summary:
  Emit .actual_access metadata for the deduced argument access qualifier,
and .access for kernel_arg_access_qual.

Reviewers:
 arsenm

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

Previously, for linking in amdgpu contexts, the --no-undefined was appended to the options passed to lld,
overriding any user-supplied options via "-Wl," or "-Xlinker". We now prepend --no-undefined so that
the user options are respected.

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

The standard suggests that the value for the `device_type` clause on the
`set` directive is a list but this does not makes sense. Restrict the number
of value to one so it matches the runtime function.

Depends on D158644

Reviewed By: razvanlupusoru

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

This is good for performance and compile time and the indirection (+
switch statements) is nothing that needs to be preserved.

The visited set was used to not visit the same function twice, however,
the (new) algorithm requires we do since we start the queries at
different call sites.

The standard suggests that the value for the `device_type` clause on the
`set` directive is a list but this does not makes sense. Restrict the number
of value to one so it matches the runtime function.

Reviewed By: razvanlupusoru

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

Fixes a long-standing bug that erroneously placed function arguments on a
new line despite all arguments being able to fit on the same line.

The original diff that introduced the bug implemented behaviour that pushed
the first argument to a function onto a new line under certain circumstances
relating passing lambdas as arguments.

This behaviour was implemented in TokenAnnotator::mustBreakBefore() which
meant the code lacked the necessary context to figure out whether subsequent
arguments might be able to all fit on one line. As such, I've moved the
implementation to ContinuationIndenter and, instead of forcing a line break
at the first argument in all cases, we now allow the OptimizingLineFormatter
to consider placing the first argument on the same line as the function call
but don't allow further line breaks in this case.

The end result is that either the first argument must go on a new line (as
before) or all arguments must be put on the current line.

Closes #44486.

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

We already add AMD GPU annotations, the NVIDIA ones are just a little
more convoluted to add/update but otherwise the same.
We see again that the interplay of ompx_attribute and deduced value
needs to be improved, see the TODO.

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