[mlir][Linalg] NFC - Extract inferGemmDims - Amend forgotten changes

[mlir][Linalg] NFC - Extract inferGemmDims

[LegacyPM] Remove some legacy passes

These are part of the optimization pipeline, of which the legacy pass manager version is deprecated.

Namely
* Internalize
* StripSymbols
* StripNonDebugSymbols
* StripDeadDebugInfo
* StripDeadPrototypes
* VectorCombine
* WarnMissedTransformations

[CostModel][X86] Update LV UTC_ARGS regexp filter to match ptr instead of i8* etc.

[libc] Add startup code implementation for GPU targets

This patch introduces startup code for executing `main` on a device
compiled for the GPU. We will primarily use this to run standalone
integration tests on the GPU. The actual execution of this routine will
need to be provided by a `loader` utility to bootstrap execution on the
GPU.

Reviewed By: sivachandra

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

[clang] NFC: Remove GCC 5.1 workaround in FileEntry

We no longer support GCC 5.1 (D122976), so let's remove the workaround in FileEntry.

Reviewed By: benlangmuir

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

[clang][deps] Fix race condition

D140176 introduced new `FullDeps` API that's not thread-safe, breaking the class invariant. This was causing race condition when `clang-scan-deps` was run with multiple threads.

Reviewed By: steven_wu, akyrtzi

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

[Hexagon] Add release note for LLVM 16

[X86] combineX86ShuffleChainWithExtract - refactor to remove need to widen all vectors

combineX86ShuffleChain no longer needs the candidate shuffle inputs to all have been widened to root size, but combineX86ShuffleChainWithExtract still assumes that they have.

This refactor peeks through all inputs' extract_subvector nodes to find the widest legal vector type and widens the shuffle mask accordingly - it no longer bails if any of the inputs can't be widened to the new width.

combineX86ShuffleChainWithExtract now follows a similar process to combineX86ShufflesRecursively, so I think we should eventually be able to get rid of it and just let combineX86ShufflesRecursively handle widening the shuffle width as well.

Another step toward removing subvector widening for Issue #45319

[ARM][AArch64][RISCV] Add tests for various double reductions. NFC

[CodeGen] Add standard print/debug utilities to EVT

Doing so makes it easier to do printf style debugging in idiomatic manner. I followed the code structure of Value with only the definition of dump being #ifdef out in non-debug builds. Not sure if this is the "right" option; we don't seem to have any single consistent scheme on how dump is handled.

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

[libc] Cleanup the CMake infrastructure to add startup objects.

Instead of using a custom target to copy the startup object file to a
file with the desired name, a normal object library with a special
property is used.

Follow up patches will do more cleanup wrt how the startup objects are
used in integration tests.

Reviewed By: jhuber6

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

[llvm] Add tests for upcoming fixes to pointer/index type confusion.

Various parts of the codebase are using getIntPtrType() and its
relatives when getting the type of the offset argument to GEP. Most
such code has been updated to use the pointer index type field from
the data layout, but there is code that still assumes these two types
are the same in certain optimizaiton passes.

This commit adds regression tests to capture the old behavior.

Reviewed By: #amdgpu, arsenm

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

[mlir][doc] Remove outdated section about a deprecated `OpBuilder` use

This syntax has been removed two years ago in https://github.com/llvm/llvm-project/commit/2f5569f6f67a30f7774f7c2d2f3d726752a862ae yet the doc still had a section marking them as deprecated

[Flang] [Semantics] More descript warning message for same named external statements and interfaces

For issue: https://github.com/llvm/llvm-project/issues/56605. Previous error messages are not descriptive of problem. Issuing warnings instead that do not halt compilation but offer better description of problem.

Reviewed By: klausler

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

[OpenMP][libomp] Remove false positive for memory sanitizer

The memory sanitizer intercepts the memcpy() call but not the direct
assignment of last byte to 0. This leads the sanitizer to believe the
last byte of a string based on the kmp_str_buf_t type is uninitialized.
Hence, the eventual strlen() inside __kmp_env_dump() leads to an
use-of-uninitialized-value warning.

Using strncat() instead gives the sanitizer the information it needs.

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

Fixes #60501

[WebAssembly][test][NFC] Add coverage of non-void funcref calls

This is trickier to handle in some other representations of funcrefs
that are being explored, so it makes sense to ensure we have some
coverage of this requirement.

[HWASAN] Remove GetRequestedSize check from Metadata::IsAllocated

After D143438 there is no point in this check as the size will never 0. Also this keeps it consistent with ASAN where there is not size check in LsanMetadata::allocated.

Reviewed By: MaskRay, vitalybuka

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

[mlir][ods] add mechanism for deprecating an `OpBuilder` in ODS

This allows discouraging the use of specific build methods of an op by having TableGen generate C++ code, instructing the C++ compiler to warn on use of the `build` method.
The implementation uses the C++14 `[[deprecated(...)]]`` for this purpose. I considered using `LLVM_DEPRECATED`, but thought requiring a fix-it was not necassery, nor would the syntax in ODS have been very nice.

My motivation for this change is that in the future I'd like to deprecate the use `build` methods in the LLVM Dialect, not using explicit pointer types for ops such as `llvm.load` or `llvm.alloca`, which makes the code not future proof for opaque pointers. In-tree has to be clean first before I could commit such a change of course, but I thought the initial infrastructure change could already be submitted.

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

[mlir] Switch default Fold API to using FoldAdaptors

As mentioned in https://discourse.llvm.org/t/psa-new-improved-fold-method-signature-has-landed-please-update-your-downstream-projects/67618, it has now been about one month since the new fold API has been introduced.

Any downstream users that have not yet switched, nor explicitly set useFoldAPI to kEmitRawAttributesFolder will experience a build break after this patch, requiring them to either switch to the new API or explicitly use the old one and live with the warning set by TableGen.

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

[WebAssembly][test][NFC] Regenerate funcref-call.ll using update_llc_test_checks.py

In preparation for some slight expansion of the tests.

[libc++] Remove #error about _LIBCPP_DEBUG

This doesn't require a release note since this used to be an error,
so nobody should have been using it anymore.

[libc++] Use __builtin_FILE and __builtin_LINE in _LIBCPP_ASSERT

This avoids theoretical potential ODR violations since __LINE__ and
__FILE__ expand to different things depending on where they are.

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

[libc++][NFC] Reformat __assert with clang-format

[Flang] Restrict emit-asm-from-mlir.mlir to be ran on specific targets using 'target=...'

This patch aims to restrict the emit-asm-from-mlir.mlir test to the targets that
the test cases expect using the 'target=...' LIT expression.

rG9067de2a43145411eff8b7782a404c5834249717 has previously attempted to resolve
the LIT failure on the ppc64le-flang-rhel-clang buildbot coming from the
emit-asm-from-mlir.mlir test by restricting the test case for AArch64, x86 and
ARM (as long as these targets are built). The original solution of adding
"*-registered-target" works on ppc64le-flang-rhel-clang because this bot only
builds PowerPC in LLVM_TARGETS_TO_BUILD.

When we build all targets and also build the flang project, this test case will
fail because despite being on PowerPC, we are still building the AArch64, x86
and ARM targets which will cause this test to run. These targets expect the ret
instruction to be produced in this test case, while PowerPC produces a blr instead.

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

[libc++][format] Fixes constexpr validation.

The constexpr validation parsed parts of the format string that didn't
belong to the specific replacement field.

Fixes https://llvm.org/PR60536

Reviewed By: #libc, ldionne

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

[flang][hlfir] Emit hlfir.declare inside internal procedures

Captured variables inside internal procedure do not go though
Fortran::lower::instantiateVar because the specification expressions
should no be lowered again, and instead, all the information must be
taken from the host link argument.

There is nothing very special to do for HLFIR, but the hlfir.declare
should be emitted for the instantiated captured variable and mapped
to the symbol.

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

[flang][hlfir] Lower evaluate::DescriptorInquiry

Lower extents and lower bounds inquiries with a compile time
constant DIM that cannot be folded by the front-end.

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

[ARM] Perform lane interleaving from reductions.

We have a pass for MVE to perform lane interleaving to make use of top/bottom
instructions, that adds shuffles before extends and after truncates. This
extends it to also start from add reductions, where the order of lanes does not
matter so the shuffle is not needed. We need to be careful about not breaking
the form of existing reductions, but otherwise can save some instructions and
awkward extends.

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

Fix broken Bazel targets

[clangd] Fix a crash in semantic highlighting.

We encounter a few internal reports that we're dereference a nullptr.
Unfortunately, no small reproduce testcase for this crash yet, but it makes the
clangd more robost on broken code.

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

[include-mapping] Regenerate the StdSymbolMap.inc from the 20220730 html book.

Merge the zoombie names into the StdSymbols as well.

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

[mlir][scf] Fix builder of WhileOp with region builder arguments.

The overload of WhileOp::build with arguments for builder functions for
the regions of the op was broken: It did not compute correctly the types
(and locations) of the region arguments, which lead to failed assertions
when the result types were different from the operand types.
Specifically, it used the result types (and operand locations) for *both*
regions, instead of the operand types (and locations) for the 'before'
region and the result types (and loecations) for the 'after' region.

Reviewed By: Mogball, mehdi_amini

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

[include-mapping] Better #includes support for std input/output symbols

Reviewed By: kadircet

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

[Tooling/Inclusion] Support multiple headers in the stdlib APIs.

Unittest will be added in https://reviews.llvm.org/D143280

Patch by Viktoriia Bakalova.

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

[libc][NFC] Move attributes from common to macros folder

[libc][NFC] Sort dependencies

[libc][NFC] Use LIBC_TARGET_IS_GPU instead of defining PACKAGE_FOR_GPU

[NFC][TargetParser] Remove llvm/ADT/Triple.h

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.

[debug-info] Followup to e0374fb2f4, avoid changing codegen

As discussed on D140404, calling GetValueInMiddleOfBlock can force PHI
nodes to be created, but the patch was only supposed to fetch a Value if it
wasn't going to generate any PHIs. Fix this by using GetValueAtEndOfBlock
instead of the Middle variant, which was the original intention given the
check of HasValueForBlock.

We don't need to consider the "middle of block" scenario as we're only
dealing with blocks where there are no value definitions.

[CodeGen] Make more use of MachineOperand::getOperandNo. NFC.

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

[CodeGen] Define and use MachineOperand::getOperandNo

This is a helper function to very slightly simplify many calls to
MachineInstruction::getOperandNo.

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

[AMDGPU] Remove the unused u8imm operand definition.

Reviewed By: foad

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

[LoopVectorize] Use DataLayout::getIndexType instead of i32 for non-constant GEP indices.

This is specifically relevant for loops that vectorize using a scalable VF,
where the code results in:

  %vscale = call i32 llvm.vscale.i32()
  %vf.part1 = mul i32 %vscale, 4
  %gep = getelementptr  ..., i32 %vf.part1

Which InstCombine then changes into:

  %vscale = call i32 llvm.vscale.i32()
  %vf.part1 = mul i32 %vscale, 4
  %vf.part1.zext = sext i32 %vf.part1 to i64
  %gep = getelementptr  ..., i32 %vf.part1.zext

D143016 tried to remove these extends, but that only works when
the call to llvm.vscale.i32() has a single use. After doing any
kind of CSE on these calls the combine no longer kicks in.

It seems more sensible to ask DataLayout what type to use, rather
than relying on InstCombine to insert the extend and hoping it can
fold it away.

I've only changed this for indices that are not constant, because
I vaguely remember there was a reason for sticking with i32. It
would also mean patching up loads more tests.

Reviewed By: paulwalker-arm

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

[clang-tidy] Fix `cppcoreguidelines-init-variables` for invalid vardecl

https://godbolt.org/z/n4cK4fo3o
The checker missed a check for invalid vardecl and this could cause a false positive.

Reviewed By: carlosgalvezp

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

[AArch64][SME2] Add multi-vector frint intrinsics

Adds x2 and x4 vector intrinsics for the following instructions:
 - frinta
 - frintm
 - frintn
 - frintp

NOTE: These intrinsics are still in development and are subject to future changes.

Reviewed By: david-arm

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

[ARM] Tests for lane interleaving from reductions. NFC

[libc][NFC] Rename compiler_feature macros

[libc][NFC] Move sanitizer to macros folder

[AArch64][SME2] Add multi-vector floating point min/max number intrinsics

Adds IR intrinsics for the following SME2 instructions:
 - fmaxnm/fminnm (single, 2 & 4 vector)
 - fmaxnm/fminnm (multi, 2 & 4 vector)

NOTE: These intrinsics are still in development and are subject to future changes.

Reviewed By: david-arm

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

[NFC][TargetParser] Remove llvm/Support/TargetParser.h

[NFC][TargetParser] Remove llvm/Support/X86TargetParser.h

[NFC][TargetParser] Remove llvm/Support/X86TargetParser.def

[NFC][TargetParser] Remove llvm/Support/LoongArchTargetParser.h

[NFC][TargetParser] Remove llvm/Support/CSKYTargetParser.h

[NFC][TargetParser] Remove llvm/Support/ARMTargetParserCommon.h

[NFC][TargetParser] Remove llvm/Support/ARMTargetParser.h

[SDAG] Check fminnum/fmaxnum for non-zero operand.

Currently, in TargetLowering, if the target does not support fminnum, we lower
to fminimum if neither operand could be a NaN. But this isn't quite correct
because fminnum and fminimum treat +/-0 differently; so, we need to prove that
one of the operands isn't a zero, or we don't have signed zeros.

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

[NFC] minnum/maxnum intrinsic tests

ARM and WebAssembly tests.

[ARM] Remove reduce(shuffle) if all the lanes are used

This looks for vaddv(shuffle) or vmlav(shuffle, shuffle), with a shuffle where
all the lanes are used once. Due to the reduction being commutative the shuffle
can be removed.

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

[libc][NFC] Move compiler_features to macros folder

[mlir][bufferize] Add noAnalysisFuncFilter to OneShotBufferizationOptions struct

This change is needed in order to set the flag when running the pass not via the command line.
It also allows simplifying the signature of some functions.

Reviewed By: springerm

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

Revert "[DAGCombine] Fold redundant select"

This reverts commit bbdf24357932b064f2aa18ea1356b474e0220dde.

[libc][NFC] Move cpu_features to macros folder

[flang] add -fstack-arrays flag

The implementation of -fstack-arrays was added in
https://reviews.llvm.org/D140415

The new macro BoolOptionWithoutMarshalling in Options.td avoids
generating code to store the flags in clang data structures. For
example, writing something like

  defm stack_arrays : BoolOption<"f", "stack-arrays",
                                 CodeGenOpts<"StackArrays">, [...]

Would generate code referring to `clang::CodeGenOpts::StackArrays`, which
does not exist.

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

[flang] add a pass to move array temporaries to the stack

This pass implements the `-fstack-arrays` flag. See the RFC in
`flang/docs/fstack-arrays.md` for more information.

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

[libc][NFC] Rename architecture macros and move to macros folder

[ARM] Add various tests for reductions of shuffles. NFC

[PHITransAddr] Simplify casts in PHITransAddr

Try to simplify cast in similar way as for GEP and ADD with
constant (e.g. sext/zext + trunc).

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

[NFC] Add pre-commit test for simplifyCastInst in PHITransAddr

[NFC][clang] Fix static analyzer concern about uninitialized variable

Reviewed By: xazax.hun

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

[libc][doc] Update compiler

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

[Tooling/Inclusion] Move the StdSpecialSymbolMap.inc to the private lib place.

I missed it in c751264aa19865beab12d94db3ea966c6accd428.

[libc][doc] Add macros guidelines

This is a first follow up on the libc tuning RFC
https://discourse.llvm.org/t/rfc-llvm-libc-tuning/67980

Once we agree on the format. I'll land a couple of patches to match the guidelines.

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

[Tooling/Inclusion] Introduce a human-edit file for C++ std symbols

This file is allowed to be edit by human, and it overlays the generated symbol file.
It contains a list of multiple-header symbols.
This patch introduces the file only. Usage will come afterwards.

Reviewed By: kadircet

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

[Tooling/Inclusion] Move the generated mapping .inc file to private places.

The .inc files are private now, clients should tooling::stdlib APIs instead.

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

[flang][hlfir] place scalar in memory in convertToBox/convertToAddress

Implement the TODO. Be careful to use and propagate the expression
type to create the temporary since the mlir value may have been computed
with a different value type (e.g., i1 for logical) that should not be
used for in memory values that must have Fortran types.

Co-authored-by: Tom Eccles <tom.eccles@arm.com>
Differential Revision: https://reviews.llvm.org/D143421

[flang][NFC] addSymbol/lookupSymbol clean-up

HLFIR requires mapping symbol to a single mlir::Value (produced
by a fir::FortranVariableOpInterface), while the current lowering
maps the value to a fir::ExtdendedValue.

So far, the HLFIR symbol query was a special one. Hence, all the code
directly using symMap.lookupSymbol and symMap.addSymbol did not work
with the lowering to HLFIR.

Refactor the code so that symbol lookup and add symbol go through
the converter in a centralize place that handles the HLFIR case
(translate fir::FortranVariableOpInterface to fir::ExtdendedValue
in lookups, and generate hlfir.declare when adding symbols).

In the refactoring, fir::FortranVariableOpInterface is added as
a symbolBox variant to avoid special casing all lookups (shallowLookup...).

Remove some unused SymbolBox member function instead of updating
them.

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

[flang] Use PointerAssociateLowerBounds when there is lower bounds

The current code was not taking provided lower bounds when the pointer
is polymorphic and was just calling PointerAssociate. This patch
updates the behavior and use PointerAssociateLowerBounds with the provided
lower bounds.

Reviewed By: jeanPerier

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

[cmake] Use LLVM_ENABLE_ASSERTIONS to enable assertions in libstdc++

On my machine this showed no new failures in check-llvm and increased
the testing time from 138 to 142 seconds, for a Release build with
assertions enabled.

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

[IR] Fix bug in DemoteRegToStack where DenseMap is not used

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

[lldb] Fix typo in LoongArch unittest

[SCEV] Support sext in SCEVLoopGuardRewriter

There is no particular reason why it's not supported, and it is useful.

Differential Revision: https://reviews.llvm.org/D143257
Reviewed By: fhahn

[mlir][linalg] Check for tensor of 0 dims during vectorization

tensor with dims of size 0 cannot be vectorized. Add precondition to
prevent a crash in vectorization.

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

[C++20] [Modules] Allow ADL in dependent context for modules

Close https://github.com/llvm/llvm-project/issues/60488.

Previously, when we instantiate a template, the argument dependent
lookup is performed in the context of the instantiation, which implies that the
functions not visible in the context can't be found by the argument
dependent lookup.

But this is not true, according to [module.context]p3, the instantiation
context for the implicit instantiation of a template should contain the
context of the primary module interface if the template is defined in
the module interface unit.

Note that the fix didn't implemnet [module.context]p3 precisely, see the
comments for example.

[mlir]: Added IntArrayNthElemMaxValue & IntArrayNthElemInRange predicates (NFC)

Reviewed By: rriddle

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

[SCEV][NFC] Remove check for rewriteable types

I guess its only reason to exist is potential CT optimization, otherwise it is
just creating cohesion between this code and rewriter internals. We plan to
extend the rewriter. I'd rather not have this cohesion, unless there is a serious
reason to have it.

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

[DAGCombiner] fix comments for D138899; NFC

[RISCV] Refactor RISCVDisassembler::getInstruction to remove repeated code. NFC

For 4 byte instructions we were always setting size to 4 eventually. Same
for 2 byte instructions. So do it as soon as we know the from the opcode.

Add a return to the end of the 4 byte code so we don't have to have an else
around the 2 byte code.

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

[libc++][NFC] _VSTD -> std in ryu

Those ones are extremely mechanical and since that's not libc++ code
in the first place, there's even more of an incentive to do the rename.

[libc++] Add missing _LIBCPP_HIDE_FROM_ABI

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

MIPS: fix build from IR files, nan2008 and FpAbi

When we use llc or lld to compiler IR files, the features +nan2008 and +fpxx/+fp64 are not used.
Thus wrong format files are produced.

In IR files, the attributes are only set for function while not the whole compile units.
So we extract the attributes from the first function and use it for the whole unit.

isFPXXDefault: for o32, the FPXX should always be the default, no matter about the vendors.
Of course some distributions with FP64 default enabled should be listed explicit.
Let's add them in future if we know about one.

Reviewed By: MaskRay

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

[Instcombine] Precommit tests for D143373; NFC

[libc++] Fix path to versioned clang-format in the CI job

[AArch64][SVE] Fix crash for DestructiveBinaryCommWithRev zero merging

Address more Destructive type according the review on D141471

* DestructiveUnaryPassthru and DestructiveBinaryImm always return true, don't need fix
* DestructiveTernaryCommWithRev may also return false, but now don't define FalseLanesZero in the backend codegen

Reviewed By: paulwalker-arm

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

[AArch64][SVE] Replace destructive operand of vector zeros with a bundled MOVPRFX instruction

Replace unary instructions where the destructive operand is a vector of zeros
with a bundled MOVPRFX instruction, e.g:
       Transform:
           %X0 = DUP_ZI_S 0, 0
           %X0 = FLOGB_ZPmZ_S X0, P0, X2
        into:
            X0 = MOVPRFX P0/z, X1  // doesn't introduce any fake register dependencies compare to X0 = MOVPRFX P0/z, X0
            X0 = FLOGB_ZPmZ_S X0, P0, X2
NOTE: This patch add a @earlyclobber constraint to PredOneOpPassthruPseudo to ensure
    safe register allocation for movprfx usage.

Depends on D105889

Reviewed By: paulwalker-arm

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

Revert "[RISCV] Allow mismatched SmallDataLimit and use Min for conflicting values"

This reverts commit 28bd84f55fc087d4aefd3fe5360f8648d1d50980 because
`CodeGen/RISCV/rvv-intrinsics-handcrafted/vlenb.c` hasn't been updated.

[libc++] Export CXX and CC env vars in format and documentation CI jobs

This is necessary now that the Docker images don't contain unversionned
clang binaries.

[BOLT] Reintroduce allow-stripped

Reject stripped binaries as a policy.

The core issue with stripped binaries is that we can't detect the presence
of split functions which require extra handling. Therefore BOLT can't ensure
functional correctness of produced binary if the input stripped binary contains
split functions. Supporting such cases is an interesting problem but it goes
against BOLT's intended goal of achieving peak program performance.

Reviewed By: maksfb

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

[BOLT][NFC] Replace anonymous namespace functions with static

Follow LLVM Coding Standards guideline on using anonymous namespaces
(https://llvm.org/docs/CodingStandards.html#anonymous-namespaces)
and use `static` modifier for function definitions.

Reviewed By: #bolt, maksfb

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