Revert "[RISCV] Implement support for bf16 truncate/extend on hard FP targets"

This was committed with D153598 merged into it. Reverting to recommit as separate patches.

This reverts commit 690b1c847f0b188202a86dc25a0a76fd8c4618f4.

[Attributor][NFC] Avoid string concat for non-tracing runs

[Attributor] Check IR attributes before creating new AAs

Instead of creating an AA for an IR attribute we can first check if it
is implied/known. If so, we can save the time to create the AA, figure
out it is implied, fix it, and later manifest it in the IR
(redundantly). Other IR attributes can be added to the list in
`AA::hasAssumedIRAttr` later on, for now we support 8 different ones.

[Attributor][NFCI] Use pointers to pass around AAs

This will make it easier to create less trivial AAs in the future as we
can simply return `nullptr` rather than an AA with in invalid state.

[gn build] Port 44265dc3554e

[LTO][GlobalDCE] Use pass parameter instead of module flag for LTO phase

D63932 added a module flag to indicate that we are executing the regular
LTO post merge pipeline, so that GlobalDCE could perform more aggressive
optimization for Dead Virtual Function Elimination. This caused issues
trying to reuse bitcode that had already been through the LTO pipeline
(see context in D139816).

Instead support this by passing down a parameter flag to the
GlobalDCEPass constructor, which is the more usual way for indicating
this information.

Most test changes are to remove incidental uses of this flag. Of the 2
real uses, llvm/test/LTO/ARM/lto-linking-metadata.ll is now obsolete and
removed in this patch, and the virtual-functions-visibility-post-lto.ll
test is updated to use the regular LTO default pipeline where this
parameter is set to true.

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

[RISCV] Split ReadSFB into ReadSFBJmp and ReadSFBALU.

The operands may need to be available at different times.

clang: Add missing cases to elementwise builtin SemaCXX test

clang: Add __builtin_elementwise_rint and nearbyint

These are basically the same thing and only differ for strictfp,
so add both for future proofing. Note all the elementwise functions are
currently broken for strictfp, and use non-constrained ops. Add a test
that demonstrates this, but doesn't attempt to fix it.

[Pseudo Probe] Remove the assert of allowing only one call probe for a callsite.

Compiler-generated static symbols, such as the global initializers, can shared the same name and can coexist in the binary. As a result, their pseudo probes are all kept in the binary too. This could cause multiple call probes decoded against one callsite, as probes are decoded against there owning functions by name. I'm temporarily disabling an assert to keep the debug build green until we have a better fix.

Reviewed By: wenlei

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

clang: Fix elementwise value naming to match instruction

[Attributor][NFC] Allow to restrict the Attributor to cached passes

If the user wants to avoid running additional passes, they can now
initialize the AnalysisGetter accordingly.

[Attributor] Remove the iteration count verification

It was never really useful to track #iterations, though it helped during
the initial development. What we should track, in a follow up, are
potentially #updates. That is also what we should restrict instead of
the #iterations.

ValueTracking: Use new version of cannotBeOrderedLessThanZero

Pass all arguments so now assumes work.

ValueTracking: Prepare to phase out CannotBeOrderedLessThanZero

Introduce a full featured wrapper around computeKnownFPClass
to start replacing the uses with.

Reland [llvm] Preliminary fat-lto-objects support

Fat LTO objects contain both LTO compatible IR, as well as generated
object code. This allows users to defer the choice of whether to use LTO
or not to link-time. This is a feature available in GCC for some time,
and makes the existing -ffat-lto-objects flag functional in the same
way as GCC's.

Within LLVM, we add a new EmbedBitcodePass that serializes the module to
the object file, and expose a new pass pipeline for compiling fat
objects. The new pipeline initially clones the module and runs the
selected (Thin)LTOPrelink pipeline, after which it will serialize the
module into a `.llvm.lto` section of an ELF file. When compiling for
(Thin)LTO, this normally the point at which the compiler would emit a
object file containing the bitcode and metadata.

After that point we compile the original module using the
PerModuleDefaultPipeline used for non-LTO compilation. We generate
standard object files at the end of this pipeline, which contain machine
code and the new `.llvm.lto` section containing bitcode.

Since the two pipelines operate on different copies of the module, we
can be sure that the bitcode in the `.llvm.lto` section and object code
in  `.text` are congruent with the existing output produced by the
default and LTO pipelines.

Original RFC: https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977

Earlier versions of this patch were missing REQUIRES lines for llc
related tests in Transforms/EmbedBitcode. Those tests are now under
CodeGen/X86, which should avoid running the check on unsupported
platforms.

Reviewed By: tejohnson, MaskRay, nikic

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

[RISCV] Implement KCFI operand bundle lowering

With `-fsanitize=kcfi` (Kernel Control-Flow Integrity), Clang emits
"kcfi" operand bundles to indirect call instructions. Similarly to
the target-specific lowering added in D119296, implement KCFI operand
bundle lowering for RISC-V.

This patch disables the generic KCFI pass for RISC-V in Clang, and
adds the KCFI machine function pass in `RISCVPassConfig::addPreSched`
to emit target-specific `KCFI_CHECK` pseudo instructions before calls
that have KCFI operand bundles. The machine function pass also bundles
the instructions to ensure we emit the checks immediately before the
calls, which is not possible with the generic pass.

`KCFI_CHECK` instructions are lowered in `RISCVAsmPrinter` to a
contiguous code sequence that traps if the expected hash in the
operand bundle doesn't match the hash before the target function
address. This patch emits an `ebreak` instruction for error handling
to match the Linux kernel's `BUG()` implementation. Just like for X86,
we also emit trap locations to a `.kcfi_traps` section to support
error handling, as we cannot embed additional information to the trap
instruction itself.

Relands commit 62fa708ceb027713b386c7e0efda994f8bdc27e2 with fixed
tests.

Reviewed By: MaskRay

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

Fix missing return introduced when adding support for properties in MLIR in 5e118f933b659

This is a rarely used API: `matchAndRewrite()` is the usual way of using
patterns.

ValueTracking: Handle cannotBeOrderedLessThanZero for fadd

Move cannotBeOrderedLessThanZero logic into computeKnownFPClass.

[llvm-profdata] Fix mixed-sign comparison warnings

This patch fixes -Wsign-compare warnings from:

  llvm/unittests/tools/llvm-profdata/MD5CollisionTest.cpp:117:3: note:
  in instantiation of function template specialization
  'testing::internal::EqHelper::Compare<unsigned long, int, nullptr>'
  requested here

  llvm/unittests/tools/llvm-profdata/MD5CollisionTest.cpp:134:3: note:
  in instantiation of function template specialization
  'testing::internal::EqHelper::Compare<unsigned int, int, nullptr>'
  requested here

  llvm/unittests/tools/llvm-profdata/MD5CollisionTest.cpp:144:3: note:
  in instantiation of function template specialization
  'testing::internal::EqHelper::Compare<unsigned int, int, nullptr>'
  requested here

  llvm/unittests/tools/llvm-profdata/MD5CollisionTest.cpp:160:3: note:
  in instantiation of function template specialization
  'testing::internal::EqHelper::Compare<unsigned int, int, nullptr>'
  requested here

[test][msan] Add test for dc4d9d6

[msan] Optimize zeroing allocated memory

Reviewed By: thurston

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

[gn build] Port 31af18bccea9

[llvm-profdata] Refactoring Sample Profile Reader to increase FDO build speed using MD5 as key to Sample Profile map

This is phase 1 of multiple planned improvements on the sample profile loader.   The major change is to use MD5 hash code ((instead of the function itself) as the key to look up the function offset table and the profiles, which significantly reduce the time it takes to construct the map.

The optimization is based on the fact that many practical sample profiles are using MD5 values for function names to reduce profile size, so we shouldn't need to convert the MD5 to a string and then to a SampleContext and use it as the map's key, because it's extremely slow.

Several changes to note:

(1) For non-CS SampleContext, if it is already MD5 string, the hash value will be its integral value, instead of hashing the MD5 again. In phase 2 this is going to be optimized further using a union to represent MD5 function (without converting it to string) and regular function names.

(2) The SampleProfileMap is a wrapper to *map<uint64_t, FunctionSamples>, while providing interface allowing using SampleContext as key, so that existing code still work. It will check for MD5 collision (unlikely but not too unlikely, since we only takes the lower 64 bits) and handle it to at least guarantee compilation correctness (conflicting old profile is dropped, instead of returning an old profile with inconsistent context). Other code should not try to use MD5 as key to access the map directly, because it will not be able to handle MD5 collision at all. (see exception at (5) )

(3) Any SampleProfileMap::emplace() followed by SampleContext assignment if newly inserted, should be replaced with SampleProfileMap::Create(), which does the same thing.

(4) Previously we ensure an invariant that in SampleProfileMap, the key is equal to the Context of the value, for profile map that is eventually being used for output (as in llvm-profdata/llvm-profgen). Since the key became MD5 hash, only the value keeps the context now, in several places where an intermediate SampleProfileMap is created, each new FunctionSample's context is set immediately after insertion, which is necessary to "remember" the context otherwise irretrievable.

(5) When reading a profile, we cache the MD5 values of all functions, because they are used at least twice (one to index into FuncOffsetTable, the other into SampleProfileMap, more if there are additional sections), in this case the SampleProfileMap is directly accessed with MD5 value so that we don't recalculate it each time (expensive)

Performance impact:
When reading a ~1GB extbinary profile (fixed length MD5, not compressed) with 10 million function names and 2.5 million top level functions (non CS functions, each function has varying nesting level from 0 to 20), this patch improves the function offset table loading time by 20%, and improves full profile read by 5%.

Reviewed By: davidxl, snehasish

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

Revert "[RISCV] Implement KCFI operand bundle lowering"

This reverts commit 62fa708ceb027713b386c7e0efda994f8bdc27e2.

Reverting to investigate -verify-machineinstrs errors in MIR tests.

[WebAssembly] Add lowering for llvm.rint and llvm.roundeven

WebAssembly doesn't expose inexact exceptions, so frint can be mapped to
fnearbyint. Likewise, WebAssembly always rounds ties-to-even, so
froundeven can be mapped to fnearbyint.

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

Darwin: Use the GOT to reference ___stack_chk_guard.

e018cbf7208b changed the default behaviour for Darwin, and this breaks some
existing software.

rdar://110350601

[libc] Add basic utility support for timing functions on the GPU

This patch adds the utilities for the clocks on the GPU. This is done
prior to exporting it via some other interface and is mainly just done
so they are availible if we wish to do internal testing.

Reviewed By: lntue

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

[ClangPackager] Add an option to extract inputs to an archive

Currently we simply overwrite the output file if we get muliple matches
in the fatbinary. This patch introduces the `--archive` option which
allows us to combine all of the files into a static archive instead.
This is usefuly for creating a device specific static archive library
from a fatbinary.

Reviewed By: JonChesterfield

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

[ConstraintElim] Add tests to check negated OR simplifications.

Additional test coverage for D151799.

Revert "OpenMP/cmake: Use list append instead of repeating variable name"

This reverts commit e429fdd036957f570f624fee4e79a480ff2ec90e.

[libc][Obvious] Use the current binary dir instead of the base one

Summary:
We include things off of `libc/include` so we need to use the current
binary dir when setting up the directory.

[mlir][math] Modified the 'math.exp' lowering for higher precision

The existing lowering has lower precision for certain use cases, e.g.
tanh. Improved version should demonstrate an overall higher level of precision.

Reviewed By: cota, jpienaar

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

OpenMP/cmake: Use DEPFILE instead of IMPLICIT_DEPENDS

IMPLICIT_DEPENDS doesn't actually work with ninja and this does.

OpenMP/cmake: Use list append instead of repeating variable name

When float_t and double_t types are used inside a scope with
a '#pragma clang fp eval_method, it can lead to ABI breakage.
See https://godbolt.org/z/56zG4Wo91
This patch prevents this.

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

[gn build] Port a3800ad9d87f

[lldb] Use format specific for unprintabe char in DumpDataExtractor

Addresses Jason's post-commit feedback in D153644.

[scudo] PopBatch after populateFreeList()

Ensure the thread that refills freelist will get the Batch without
contending the lock in SizeClassAllocator64.

Reviewed By: cferris

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

[scudo] update Pushedblocks/PoppedBlocks in Impl functions

Reviewed By: cferris

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

[libc] Fix installing GPU headers

The patch in D152592 changed the logic for this. We could never check if
we were on the GPU as this was before the variable was defined so I
moved it later. Secondly, we cannot use the `LLVM_BINARY_DIR` here, and
I do not know if that works in general. The problem is that it will
isntall the headers under a normal path outside of the
`LLVM_ENABLE_RUNTIMES` build. I don't know if that's correct for the
other targets, but for the GPU I need to set it back to the
CMAKE_BINARY_DIR so it works.

Reviewed By: phosek

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

Revert "[llvm] Preliminary fat-lto-objects support"

There seems to be a problem on arm buildbots. Reverting until I can
investigate.  https://lab.llvm.org/buildbot#builders/245/builds/10184

This reverts commit a67208e1c697649ce432e6497f56a93675273dd8
and dependent commit e54a3112cee5ae0a9117359ecbea878e1388f51e.

[RISCV] Implement KCFI operand bundle lowering

With `-fsanitize=kcfi` (Kernel Control-Flow Integrity), Clang emits
"kcfi" operand bundles to indirect call instructions. Similarly to
the target-specific lowering added in D119296, implement KCFI operand
bundle lowering for RISC-V.

This patch disables the generic KCFI pass for RISC-V in Clang, and
adds the KCFI machine function pass in `RISCVPassConfig::addPreSched`
to emit target-specific `KCFI_CHECK` pseudo instructions before calls
that have KCFI operand bundles. The machine function pass also bundles
the instructions to ensure we emit the checks immediately before the
calls, which is not possible with the generic pass.

`KCFI_CHECK` instructions are lowered in `RISCVAsmPrinter` to a
contiguous code sequence that traps if the expected hash in the
operand bundle doesn't match the hash before the target function
address. This patch emits an `ebreak` instruction for error handling
to match the Linux kernel's `BUG()` implementation. Just like for X86,
we also emit trap locations to a `.kcfi_traps` section to support
error handling, as we cannot embed additional information to the trap
instruction itself.

Reviewed By: MaskRay

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

[gn build] Port a67208e1c697

Remove unused include. NFC

[lldb] Print unprintable characters as unsigned

When specifying the C-string format for dumping memory, we treat
unprintable characters as signed. Whether a character is signed or not
is implementation defined, but all printable characters are signed.
Therefore it's fair to assume that unprintable characters are unsigned.

Before this patch, "\xcf\xfa\xed\xfe\f" would be printed as
"\xffffffcf\xfffffffa\xffffffed\xfffffffe\f". Now we correctly print the
original string.

rdar://111126134

Differential revision: https://reviews.llvm.org/D153644

[NVPTX] Lower v2f16 and v2bf16 stores as 32-bit scalars.

This avoids unnecessary vector splitting that was needed for vectorized store
instruction.

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

[llvm] Preliminary fat-lto-objects support

Fat LTO objects contain both LTO compatible IR, as well as generated
object code. This allows users to defer the choice of whether to use LTO
or not to link-time. This is a feature available in GCC for some time,
and makes the existing -ffat-lto-objects flag functional in the same
way as GCC's.

Within LLVM, we add a new EmbedBitcodePass that serializes the module to
the object file, and expose a new pass pipeline for compiling fat
objects. The new pipeline initially clones the module and runs the
selected (Thin)LTOPrelink pipeline, after which it will serialize the
module into a `.llvm.lto` section of an ELF file. When compiling for
(Thin)LTO, this normally the point at which the compiler would emit a
object file containing the bitcode and metadata.

After that point we compile the original module using the
PerModuleDefaultPipeline used for non-LTO compilation. We generate
standard object files at the end of this pipeline, which contain machine
code and the new `.llvm.lto` section containing bitcode.

Since the two pipelines operate on different copies of the module, we
can be sure that the bitcode in the `.llvm.lto` section and object code
in  `.text` are congruent with the existing output produced by the
default and LTO pipelines.

Original RFC: https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977

Reviewed By: tejohnson, MaskRay, nikic

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

[NVPTX] Correctly lower extending loads for fp16 vectors.

Fixes https://github.com/llvm/llvm-project/issues/63436

Improves lowering of extending FP vector loads. We were previously splitting
them unnecessarily.

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

[lldb][NFCI] Remove use of ConstString from StructuredDataPlugin

The use of ConstString in StructuredDataPlugin is unneccessary as fast
comparisons are not neeeded for StructuredDataPlugins.

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

[flang][mlir][openacc] Add acc.reduction operation as data entry operation

acc.reduction operation is used as data entry operation for the reduction
operands.

Reviewed By: jeanPerier

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

[llvm-profgen] Remove target triple check to allow for more targets

Llvm-profgen internally uses the llvm libraries and the MCDesc interface to do disassembling and symblization and it never checks against target-specific instruction operators. This makes it quite transparent to targets and a first attempt for an aarch64 binary just works. Therefore I'm removing the unnecessary triple check to unblock for new targets.

Reviewed By: wenlei

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

[llvm-addr2line] Replace checkFileExists with getOrCreateModuleInfo

GNU addr2line exits immediately if -e (default to a.out) specifies a file that
cannot be open or a directory. llvm-addr2line used to wait for input on if the
input file cannot be open and addresses are not specified in command line.
Replace the D147652 checkFileExists with getOrCreateModuleInfo to avoid
a separate `sys::fs::status` operation.

Reviewed By: sepavloff

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

[LoopSink] Allow sinking to PHI-use (2nd attempt)

This change allows sinking defs from loop preheader with PHI-use into loop body. Loop sink can now see through PHI-use and select incoming blocks of value being used as candidate sink destination.

It makes loop sink more effective so more LICM can be undone if proven unprofitable with profile info. It addresses the motivating case in D87551, without resorting to profile guided LICM which breaks canonicalization.

This is the 2nd attempt after D152772.

[flang] Enhance getTypeAsString for RecordType

Add support for RecordType in getTypeAsString

Depends on D153461

Reviewed By: razvanlupusoru, jeanPerier

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

[XRay][AArch64] Suppport __xray_customevent/__xray_typedevent

`__xray_customevent` and `__xray_typedevent` are built-in functions in Clang.
With -fxray-instrument, they are lowered to intrinsics llvm.xray.customevent and
llvm.xray.typedevent, respectively. These intrinsics are then lowered to
TargetOpcode::{PATCHABLE_EVENT_CALL,PATCHABLE_TYPED_EVENT_CALL}. The target is
responsible for generating a code sequence that calls either
`__xray_CustomEvent` (with 2 arguments) or `__xray_TypedEvent` (with 3
arguments).

Before patching, the code sequence is prefixed by a branch instruction that
skips the rest of the code sequence. After patching
(compiler-rt/lib/xray/xray_AArch64.cpp), the branch instruction becomes a NOP
and the function call will take effects.

This patch implements the lowering process for
{PATCHABLE_EVENT_CALL,PATCHABLE_TYPED_EVENT_CALL} and implements the runtime.

```
// Lowering of PATCHABLE_EVENT_CALL
.Lxray_sled_N:
  b  #24
  stp x0, x1, [sp, #-16]!
  x0 = reg of op0
  x1 = reg of op1
  bl __xray_CustomEvent
  ldrp x0, x1, [sp], #16
```

As a result, two updated tests in compiler-rt/test/xray/TestCases/Posix/ now
pass on AArch64.

Reviewed By: peter.smith

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

[clang-tidy] Document modernize-raw-string-literal check options

Add missing documentation for DelimiterStem and ReplaceShorterLiterals
options.

Fixes #54662

Reviewed By: Eugene.Zelenko

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

disable execute-only tests which are failing with expensive checks

Temporarily disabling the execute-only tests. We recently added codegen for
armv6-m, which is still in heavy development (D152795).

Disabling the tests while we're figuring out what's going on is probably the
least disruptive option, as a patch dependent on it also already landed.

[DAG] mergeTruncStores - early out if we collect more than the maximum number of stores

If we have an excessive number of stores in a single chain then the candidate WideVT may exceed the maximum width of an EVT integer type (and will assert) - but since mergeTruncStores doesn't support anything wider than a i64 store we should just early-out if we've collected more than stores than that.

Fixes #63306

[LSR] Convert some tests to opaque pointers (NFC)

[LSR] Regenerate test checks (NFC)

[ArgPromotion] Remove code for handling typed pointers (NFC)

[RISCV] Add a policy operand to VPseudoBinaryNoMaskTURoundingMode [NFC]

The template was created in D151396 but was not aware of the change in
D153067. This commit adds the operand and keep similar templates
aligned.

Reviewed By: reames, craig.topper

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

[clang-format] Respect ColumnLimit 0 line breaks in inline asm

Previously, using ColumnLimit: 0 with extended inline asm with the
BreakBeforeInlineASMColon: OnlyMultiline option (the default style),
the formatter would act as if in Always mode, meaning a line break was
added before every colon in an extended inline assembly block.

This patch respects the already existing line breaks, and doesn't add
any new ones, if in ColumnLimit 0 mode.

Behaviour with Always stays as expected, with a break before every colon
regardless of any existing line breaks.

Behaviour with Never was broken before, and remains broken with this patch,
it is just never respected in ColumnLimit 0 mode.

Fixes https://github.com/llvm/llvm-project/issues/62754

Reviewed By: HazardyKnusperkeks, owenpan

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

[InstCombine] Add created extracts to worklist

Use InstCombine's insertion helper for the created extracts, so
they become part of the worklist and will be revisited.

[DAG] Fix and expand fmin/fmax reassociation fold.

This call to reassociateReduction is used by both fminnum/fmaxnum and
fminimum/fmaximum. In adding support for fminimum/fmaximum we appear to be
fixing the use of an incorrect reduction type, which should have only applied
to minnum/maxnum.

I also believe that it doesn't need nsz and reassoc to perform the
reassociation. For float min/max it should always be valid.

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

[InstCombine] Track inserted instructions when lowering objectsize

The inserted instructions can usually be simplified. Make sure this
happens in the same InstCombine iteration by adding them to the
worklist.

We happen to get some better optimization in two cases, but this is
just a lucky accident. https://github.com/llvm/llvm-project/issues/63472
tracks implementing a fold for that case.

This doesn't track all inserted instructions yet, for that we would
also have to include those created by ObjectSizeOffsetEvaluator.

[clang][Sema] Fix comments to conform to bugprone-argument-comment (NFC)

Makes some comments conform to bugprone-argument-comment (https://clang.llvm.org/extra/clang-tidy/checks/bugprone/argument-comment.html)

[RISCV][doc] Document support for zvfbfmin and zvfbfwma

My MC layer support patches missed adding these to RISCVUsage. Also
update the link to the most recent spec PDF (including the recently
committed encoding fix for vfwmaccbf16.

[RISCV] Implement support for bf16 truncate/extend on hard FP targets

For the same reasons as D151284, this requires custom lowering of the
truncate libcall on hard float ABIs (the normal libcall code path is
used on soft ABIs).

The extend operation is implemented by a shift just as in the standard
legalisation, but needs to be custom lowered because i32 isn't a legal
type on RV64.

This patch aims to make the minimal changes that result in correct
codegen for the bfloat.ll tests.

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

HIP: Directly call trunc builtins

AMDGPU: Don't use old form of fneg in some tests

AMDGPU: Modernize exp codegen tests

Find and replace on the new log tests (plus <3 x half> which was
missing). Apparently exp10 never worked.

[RISCV][MC] Fix encoding for vfwmaccbf16

The encoding matched the one given in the bf16 extension specification
PDF, but per https://github.com/riscv/riscv-bfloat16/issues/45 it seems
this encoding was not the one that is intended and was incorrectly
modified due to an issue in the PDF generation process. This patch
corrects the opcode to 111011 from 100011.

The correct encoding is shown in the new spec PDF
<https://github.com/riscv/riscv-bfloat16/releases/tag/20230614>.

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

Fixed failed assertion w/attribute on anon unions

This amends 304d1304b7bac190b6c9733eb07be284bfc17030 to process the
declaration attributes rather than assert on them; nothing prevents an
attribute from being written on an anonymous union.

Fixes https://github.com/llvm/llvm-project/issues/48512

[lld][ARM] Add support for 16-bit thumb group relocations

This adds support for the following relocations:
 * R_ARM_THM_ALU_ABS_G0_NC
 * R_ARM_THM_ALU_ABS_G1_NC
 * R_ARM_THM_ALU_ABS_G2_NC
 * R_ARM_THM_ALU_ABS_G3
as defined in:
https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst#5615static-thumb16-relocations

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

AMDGPU: Use correct lowering for llvm.log2.f32

We previously directly codegened to v_log_f32, which is broken for
denormals. The lowering isn't complicated, you simply need to scale
denormal inputs and adjust the result. Note log and log10 are still
not accurate enough, and will be fixed separately.

[AMDGPU][GFX11] Add test coverage for 16-bit conversions, part 12.

Reviewed By: arsenm

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

AMDGPU: Add more log vector tests

[mlir][emitc] Add add and sub operations

This adds operations for binary additive operators to EmitC. The input
arguments to these ops can be EmitC pointers and thus the operations can
be used for pointer arithmetic.

Reviewed By: jpienaar

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

[clangd] Replace the hacky include-cleaner macro-reference implementation.

Now MainFileMacros preserves enough information, we perform a just-in-time
convertion to interop with include-cleaner::Macro for include-cleaer features.

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

[SCEV] Add test for alloca ranges (NFC)

[AMDGPU][AsmParser] Eliminate cvtMtbuf().

Now that we have proper support for optional operands, the standard LLVM
machinery can take care of converting parsed instructions to MCInsts.
There are likely more cases where the conversion can be done
automatically, probably with some additional treatment. The plan is to
address them separately.

Part of <https://github.com/llvm/llvm-project/issues/62629>.

Reviewed By: arsenm, foad

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

[AMDGPU][GFX11] Add test coverage for 16-bit conversions, part 10.

Reviewed By: arsenm

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

[ValueTracking] Correctly check addrspace of alloca

The DataLayout alloca address space is the address space that should
be used when creating new allocas. However, not all allocas are
required to be in this address space. The isKnownNonZero() check
should work on the actual address space of the alloca, not the
default alloca address space.

Fix a failing assertion with implicit function definitions

When implicitly defining a function in C, we would try to find an
appropriate declaration context for the function to be declared within.
However, we did not account for GNU statement expressions, which
masquerade as a compound statement and can be used in other contexts
such as within structure member declarations.

Fixes https://github.com/llvm/llvm-project/issues/48579

[Clang][Driver] Warn on invalid Arm or AArch64 baremetal target triple

A common user mistake is specifying a target of aarch64-none-eabi or
arm-none-elf whereas the correct names are aarch64-none-elf &
arm-none-eabi. Currently if a target of aarch64-none-eabi is specified
then the Generic_ELF toolchain is used, unlike aarch64-none-elf which
will use the BareMetal toolchain. This is unlikely to be intended by the
user so issue a warning that the target is invalid.

The target parser is liberal in what input it accepts so invalid triples
may yield behaviour that's sufficiently close to what the user intended.
Therefore invalid triples were used in many tests. This change updates
those tests to use valid triples.
One test (gnu-mcount.c) relies on the Generic_ELF toolchain behaviour so
change it to explicitly specify aarch64-unknown-none-gnu as the target.

Reviewed By: peter.smith, DavidSpickett

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

[CostModel] Use operands argument in getInstructionCost in more places

The current instruction's pointer operand may be different from the one
specified in the Operands argument. We should use the pointer operand
from here instead in case the user has transformed it.

This manifested itself somewhere down the line in
https://reviews.llvm.org/D149889, but I haven't been able to create a
test case on its own yet unfortunately.

Reviewed By: nikic

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

[SCEV] Use object size for allocas as well

The object size and alignment based restriction on the possible
allocation range also applies to allocas, not just globals, so
handle them as well.

We shouldn't really need any type restriction here at all, but
for now stay conservative.

[SCEV] Store getValue() result in variable (NFC)

[AArch64] Add tests for double reducts of vector.reduce.fmaximum/fminimum. NFC

Including some tests with mixed minnum/minimum reductions and removing the fast
from fmin/fmax reductions as those should not be needed.

[symbolizer] Check existence of input file in GNU mode

GNU addr2line exits immediately if it cannot open the file specified as
executable/relocatable. In contrast llvm-addr2line does not exit and, if
addresses are not specified in command line, waits for input on stdin. This
causes the test compiler-rt/test/asan/TestCases/Posix/asan-symbolize-bad-path.cc to block
forever on Gentoo (see https://reviews.llvm.org/rG27c4777f41d2ab204c1cf84ff1cccd5ba41354da#1190273).
To fix this issue the behavior llvm-addr2line now exits if
executable/relocatable file cannot be found.

It fixes https://github.com/llvm/llvm-project/issues/42099 (llvm-addr2line
does not exit when passed a non-existent file).

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

[ConstantRange] Calculate precise range for multiply by -1

These are pretty common in SCEV, so make sure we get a precise
result by mapping to the sub() operation.

Revert "Revert "[CodeGen] Extend reduction support in ComplexDeinterleaving pass to support predication""

Adds the capability to recognize SelectInst that appear in the IR.
These instructions are generated during scalable vectorization for reduction
and when the code contains conditions inside the loop body or when
"-prefer-predicate-over-epilogue=predicate-dont-vectorize" is set.

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

This reverts commit ab09654832dba5cef8baa6400fdfd3e4d1495624.

Reason: Reapplying after removing unnecessary default case in switch expression.

[ARM] generate armv6m eXecute Only (XO) code

[ARM] generate armv6m eXecute Only (XO) code for immediates, globals

Previously eXecute Only (XO) support was implemented for targets that support
MOVW/MOVT (~armv7+). See: https://reviews.llvm.org/D27449

XO prevents the compiler from generating data accesses to code sections. This
patch implements XO codegen for armv6-M, which does not support MOVW/MOVT, and
must resort to the following general pattern to avoid loads:

    movs    r3, :upper8_15:foo
    lsls    r3, #8
    adds    r3, :upper0_7:foo
    lsls    r3, #8
    adds    r3, :lower8_15:foo
    lsls    r3, #8
    adds    r3, :lower0_7:foo
    ldr     r3, [r3]

This is equivalent to the code pattern generated by GCC.

The above relocations are new to LLVM and have been implemented in a parent
patch: https://reviews.llvm.org/D149443.

This patch limits itself to implementing codegen for this pattern and enabling
XO for armv6-M in the backend.

Separate patches will follow for:
- switch tables
- replacing specific loads from constant islands which are spread out over the
  ARM backend codebase. Amongst others: FastISel, call lowering, stack frames.

Reviewed By: john.brawn

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

[NFC] clang-format GlobalISelEmitter.cpp

It was overdue for a clang-format run, and it avoids unrelated formatting changes sneaking into diffs.

[NFC] Remove leftover `inline` on some RuleMatcher functions

Accidentally copy-pasted them into the .cpp while refactoring the file in D151432
Those functions are currently only used in the .cpp so it didn't cause an issue, but it causes an undefined reference if another file attempts to use them.

[SVE ACLE] Remove DAG combines that are no longer relevant.

This patch removes DAG combines that are no longer relevant
because equivalent IR combines have been added.

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

[APFloat] Add APFloat semantic support for TF32

This diff adds APFloat support for a semantic that matches the TF32 data type
used by some accelerators (most notably GPUs from both NVIDIA and AMD).

For more information on the TF32 data type, see https://blogs.nvidia.com/blog/2020/05/14/tensorfloat-32-precision-format/.
Some intrinsics that support the TF32 data type were added in https://reviews.llvm.org/D122044.

For some discussion on supporting common semantics in `APFloat`, see similar
efforts for 8-bit formats at https://reviews.llvm.org/D146441, as well as
https://discourse.llvm.org/t/rfc-adding-the-amd-graphcore-maybe-others-float8-formats-to-apfloat/67969.

A subsequent diff will extend MLIR to use this data type. (Those changes are
not part of this diff to simplify the review process.)

Reviewed By: mehdi_amini

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

[LegacyPM] Remove LowerMatrixIntrinsicsLegacyPass and LowerMatrixIntrinsicsMinimalLegacyPass

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