Introducing rsq contract flags is wrong, and also requires some level
of approximate functions. AMDGPUCodeGenPrepare already should handle
the f32 cases with appropriate flags, and I don't see how new
situations to handle would arise during legalization (other than cases
involving the rcp intrinsic, which instcombine tries to
handle). AMDGPUCodeGenPrepare does need to learn better handling of
rcp/rsq for f64 though, which we never bothered to handle well.

Removes another obstacle to correctly lowering sqrt.

https://reviews.llvm.org/D158099

Just as in https://reviews.llvm.org/D157820, dialect registration is independent of any vendor specific libs having been linked/built/etc.

Reviewed By: rkayaith

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

Like the recently added getExactLog2 except ignore the sign bit.

https://reviews.llvm.org/D158102

When we used to treat the kernel end as as aligned barrier, assertions
at the end made sense. Now, they actually cause problems as the "writes"
are not ordered with regards to reads within the kernel. We can simply
get rid of them.

When we remove barriers, we might need to remove llvm.assume
assumptions as well. However, doing this early, thus in the module pass,
will cause us to miss out on information we might need. There are few
situations we can eliminate barriers across functions, for now we simply
disable elimination of barriers that require assumptions to be removed
during the early module pass.

PredicateBitset currently uses std::bitset, but std::bitset doesn't
have a constexpr constructor or any constexpr methods until C++23.
Each target that supports GlobalIsel has as an array of PredicateBitset
objects that currently use a global constructor.

SubtargetFeature used by the MC layer for feature bits, has its own
implementation of std::bitset that has constexpr constructor and methods
that provides all the capabilities that PredicateBitset needs.

This patch copies the implementation from SubtargetFeature, makes
it a template class, and puts it in ADT. I'll migrate SubtargetFeature
in a separate patch. Adapting all existing users to it being a template
was distracting from the goal of this patch.

This reduces the binary size of llc built with gcc 8.5.0 on my local
build by ~15k.

Reviewed By: arsenm

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

Fix "PHI node has multiple entries for the same basic block with
different incoming values!" when running operands-to-args.

https://reviews.llvm.org/D158422

We select G_CONSTANT generic opcodes by materializing the constant in a
register. G_ANYEXT is replaced with COPY.

Reviewed By: craig.topper

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

Reviewed By: rafauler

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

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