Add __builtin_FILE_NAME()

Add '__builtin_FILE_NAME()', which expands to the filename because the
full path is not always needed. It corresponds to the '__FILE_NAME__'
predefined macro and is consistent with the other '__builin' functions
added for predefined macros.

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

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

[Docs] Fix typo in LoopTerminology.

[lldb][PDB] Rename GetDeclarationForSymbol() -> AddSourceInfoToDecl()

The old name of this function was confusing for me, when I started working on the PDB parser. The new name clearifies that the function adds file, line and column (typically referred as source info) and indicates that the information is stored in the provided decl parameter.

Reviewed By: DavidSpickett

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

[SCEVExpander] Always use scevgep as name

With opaque pointers the scevgep / uglygep distinction no longer
makes sense -- GEPs are always emitted in offset-based representation.

[BOLT] Add .relr.dyn section support

Vladislav Khmelevsky,
Advanced Software Technology Lab, Huawei

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

[Clang] Stop demoting ElementCount/TypeSize conversion errors to warnings.

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

[clang] Include the error message in file reading error diagnostic

in order to provide as much information as possible to the user. The
diagnostic will now look like for example:

  error: error reading '/tmp/foo.c': Permission denied

(This addresses a FIXME from 2019, 9ef6c49baf45)

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

[libclang] Fix documentation; NFC

Fixes cc929590ad305f0d068709c7c7999f5fc6118dc9. The
CXIndexOptions::GlobalOptions data member has been replaced with the two
CXChoice data members during code review.

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

[bazel] update build for d60d3455eb2

Revert "Attributor: Add isAtFixpoint part of nofpclass handling"

This reverts commit 78313e8531c412f4b57b23e0ee04ea4a131e8d71.

Accidentally pushed

Roll back claims that we implement P0960R3 and P1975R0

We thought we had implemented these papers appropriately but have since
discovered significant issues. See discussion of the issues at:
https://github.com/llvm/llvm-project/issues/61145

The work already done on these papers is remaining in tree for the
moment while people investigate whether the issues can be fixed
forward in main. The status page is being updated so the status is
clear to users of the upcoming Clang 16 release.

Attributor: Assume handling for nofpclass

Attributor: Update test

Attributor: Add isAtFixpoint part of nofpclass handling

Attributor: Start looking at uses when inferring nofpclass

Pretty much just copy pasted from noundef handling

Attributor: Add baseline tests for nofpclass

Guess at suggestions from D145278

[clangd] Move standard options adaptor to CommandMangler

There is a discrepancy between how clangd processes CDB loaded from
JSON file on disk and pushed via LSP. Thus the same CDB pushed via
LSP protocol may not work as expected. Some difference between these two
paths is expected but we still need to insert driver mode and target from
binary name and expand response files.

Test Plan: check-clang-tools

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

[clangd] Refine logic on $0 in completion snippets

We have a workaround from D128621 that makes $0 no longer being
a placeholder to conform a vscode feature. However, we have to
refine the logic as it may suppress the last parameter placeholder
for constructor of base class because not all patterns of completion
are compound statements.

This fixes clangd/clangd#1479

Reviewed By: nridge

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

[flang][hlfir] lower hlfir.matmul_transpose to runtime call

Depends on D145960

Reviewed By: jeanPerier

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

[flang] add fused matmul-transpose to the runtime

This fused operation should run a lot faster than first transposing the
lhs array and then multiplying the matrices separately.

Based on flang/runtime/matmul.cpp

Depends on D145959

Reviewed By: klausler

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

[flang][hlfir] add matmul canonicalizer

hlfir.matmul_transpose will be lowered to a new runtime call.

A canonicalizer was chosen because
  - Alternative: a new pass for rewriting chained intrinsics - this
    would add a lot of unnecessary boilerplate.
  - Alternative: including this in the HLFIR Intrinsic Lowering pass -
    I wanted to separate these two concerns: not adding a second purpose
    complicating the intrinsic lowering pass.

With this change, the MLIR built-in canonicalization pass should be run
before the HLFIR Intrinsic Lowering pass.

Depends on D145504, D145957

Reviewed By: clementval, vzakhari

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

[flang][hlfir] add hlfir.matmul_transpose operation

This operation will be used to transform MATMUL(TRANSPOSE(a), b). The
transformation will go in the following stages:
        1. Lowering to hlfir.transpose and hlfir.matmul
        2. Canonicalise to hlfir.matmul_transpose
        3. hlfir.matmul_transpose will be lowered to FIR as a new runtime
          library call

Step 2 (and this operation) are included for consistency with the other
hlfir intrinsic operations and to avoid mixing concerns in the intrinsic
lowering pass.

In step 3, a new runtime library call is used because this operation is
most easily implemented in one go (the transposed indexing actually
makes the indexing simpler than for a normal matrix multiplication). In
the long run, it is intended that HLFIR will allow the same buffer
to be shared between different runtime calls without temporary
allocations, but in this specific case we can do even better than that
with a dedicated implementation.

This should speed up galgel from SPEC2000 (but this hadn't been tested
yet). The optimization was implemented in Classic Flang.

Reviewed By: vzakhari

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

[flang][hlfir] add a test chaining intrinsics

This test checks all of the parts of intrinsic lowering work together,
and makes sure that we can pass the hlfir.expr result of one intrinsic
as an argument to another.

Depends on D145503

Reviewed By: jeanPerier

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

[flang][hlfir] clean up intrinsic arg extended values

Depends on D145502

Reviewed By: jeanPerier

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

[flang][hlfir] move intrinsic lowering out of BufferizeHLFIR

This move is useful for a few reasons:
  - It is easier to see what the intrinsic lowering is doing when the
    operations it creates are not immediately lowered
  - When lowering a HLFIR intrinsic generates an operation which needs
    to be lowered by another pattern matcher in the same pass, MLIR will
    run that other substitution before validating and finalizing the
    original changes. This means that the erasure of operations is not
    yet visible to subsequent matchers, which hugely complicates
    transformations (in this case, hlfir.exprs cannot be rewritten
    because they are still used by the now-erased HLFIR intrinsic op.

Reviewed By: jeanPerier

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

[OpenMP] [OMPT] [8/8] Added lit tests for OMPT target callbacks

Added a new target ompt mode that depends on libomptarget OMPT support.
Added tests that verify callbacks for target regions, kernel launch,
and data transfer operations. All of them should pass on amdgpu using
make check-libomptarget.

Reviewed By: jplehr

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

[SCEV] Recognize vscale intrinsics

Now that SCEV has a dedicated vscale node type, we should also map
vscale intrinsics to it. To make sure this does not regress ranges
(which were KnownBits based previously), add support for vscale to
getRangeRef() as well.

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

[ValueTracking] Support vscale in computeConstantRange()

Add support for vscale in computeConstantRange(), based on
vscale_range attributes. This allows simplifying based on the
precise range, rather than a KnownBits approximation (which will
be off by a factor of two for the usual case of a power of two
upper bound).

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

[PassBuilder] Support O0 in default pipelines

The default and pre-link pipeline builders currently require you to
call a separate method for optimization level O0, even though they
have perfectly well-defined O0 optimization pipelines.

Accept O0 optimization level and call buildO0DefaultPipeline()
internally, so all consumers don't need to repeat this.

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

[Analysis] Make order of analysis executions more stable

When debugging and using debug-pass-manager (e.g. in regression tests)
we prefer a consistent order in which analysis passes are executed.
But when for example doing

  return MyClass(AM.getResult<LoopAnalysis>(F),
                 AM.getResult<DominatorTreeAnalysis>(F));

then the order in which LoopAnalysis and DominatorTreeAnalysis isn't
guaranteed, and might for example depend on which compiler that is
used when building LLVM.

I've not scanned the full source tree, but this fixes some occurances
of the above pattern found in lib/Analysis.

This problem was discussed briefly in review for D146206.

[LAA] Fix transitive analysis invalidation bug by implementing LoopAccessInfoManager::invalidate

The default invalidate method for analysis results is just looking
at the preserved state of the pass itself. It does not consider if
the analysis has an internal state that depend on other analyses.
Thus, we need to implement LoopAccessInfoManager::invalidate in order
to catch if LoopAccessAnalysis needs to be invalidated due to
transitive analyses such as AAManager is being invalidated. Otherwise
we might end up having references to an AAManager that is stale.

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

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

[test][MemDep] Correct the 'NOT' checks in the invalidation.ll test case. NFC

The MemoryDependenceAnalysis/invalidation.ll test case was using
  ; CHECK-NOT-AA-INVALIDATE:
but I think the intention was to use
  ; CHECK-AA-INVALIDATE-NOT:

Simply changing the checks like that would make the test fail.

The old statement that AA being stateless would result in nothing
to invalidate when doing invalidate<aa> is not true afaict.
It would be different if for example doing invalidate<basic-aa>, then
the AAManager isn't invalidated (and then neither memdep would be
invalidated). But when the AAManager itself is invalidated then we
should expect to find both "Invalidating analysis: AAManager" and
"Invalidating analysis: MemoryDependenceAnalysis" in the output.

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

[libunwind][AArch64] Unbreak building with GNU assembler

GNU assembler mandates armv8.5-a for memtag instructions. Maybe
we should remove this restriction in GNU assembler, but let's work
around it for current GNU Binutils releases.

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

Make globals used for array initialization codegen constant

As pointed out in D133835 these globals will never be written to
(they're only used for trivially copyable types), so they can always be
constant.

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

[NFC] [C++20] [Modules] Tests that the duplicated declarations in GMF
won't get generated again

As the test shows, we don't want to see the specialized function bodies
if it is already contained in the imported modules. So we can save a lot
of compiling time then.

[Target][RISCV] Update SubtargetFeature definition for RV32/RV64  (NFCI).

This is done for consistency with other Predicate/Subtargetfeature
pairs, where the second parameter of the SubtargetFeature correspond
to the NAME of the def of the Predicate associated to the
SubtargetFeature.

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

[Tools] Changed the number printing format for sorting

As part of this patch, I added the ability to add leading zeros.
This is necessary so that the generated files are sorted in ascending order.

Reviewed By: yrouban

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

[X86][MC]Fix wrong action for encode movdir64b

Movdir64b is special for its mem operand, 67 prefex can not only modify its add size,
so it's mem base and index reg should be the same type as source reg, such as
movdir64b (%rdx), rcx, and could not be movdir64b (%edx), rcx.
Now llvm-mc can encode the asm 'movdir64b (%edx), rcx' but the result is the same as
'movdir64b (%edx), ecx', which offend users' intention, while gcc will object this
action and give a warning.
I add 3 new mem descriptions to let llvm-mc to report the same error.

Reviewed By: skan, craig.topper

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

[flang] Feature list plugin

Plugin that counts the number of times each tree node occurs in a given program.  Used for test coverage.

> One thing we need...is a way to determine what features a code uses. Preferably we would also be able to determine if they are implemented or not. Just the former could be done with a visitor for the parse tree. For the latter we would continue compilation and somehow ignore todo errors but collect them - @jdoerfert

Reviewed By: jdoerfert

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

[compiler-rt] Avoid signed overflow in floatdidf.c and floatdisf.c

When compiling compiler-rt with -fsanitize=undefined and running testcases you
end up with the following warning:

UBSan: floatdisf.c:27:15: signed integer overflow: 9223372036854775807 - -1 cannot be represented in type 'di_int' (aka 'long long')

This can be avoided by doing the subtraction in a matching unsigned variant of
the type, given that the overflow is the expected result of the subtraction.

The same kind of pattern exists in floatdidf.c

This was found in an out of tree target.

Reviewed By: phosek

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

[Modules] [doc] Document the problem that we can't include headers before import declarations

[X86]add assert to confirm not-null ptr in getArithmeticReductionCost

For the function getArithmeticReductionCost, it receive a ptr and dereferce it without check,
It is called many times in getTypeBasedIntrinsicInstrCost, the ptr passed to it is inited
from line 1709.

From the code, we can not ensure the ptr VecOpTy is inited when Tys is empty or Tys[VecTyIndex]
is not a VectorType, so that the getArithmeticReductionCost will do an undefined behavior.

I add assert to it, found the ptr passed to it in llvm tests are all not nullptr, but I think the check is
still meaningful for us.

Reviewed By: RKSimon

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

Revert "[RFC][X86][MemFold] Upgrade the mechanism of auto-generated Memory Folding Table"

X86FoldTablesEmitter.cpp:386:26: runtime error: shift exponent -1 is negative

This reverts commit ca4c5331823755d5f7ae28a8bcaaa0fed21cf762.

Remove the outdated feature macro '__cpp_coroutines'

The feature macro '__cpp_coroutines' is for coroutines TS. And the
coroutines TS is deprecated. So we should remove the feature macro too.

BTW, the corresponding feature macro for standard c++ coroutines is
'__cpp_impl_coroutine'.

Recommit "[Sema] Fix null pointer dereference handleAlwaysInlineAttr."

Remove use of constexpr if that failed on the build bots.

Original commit message:

It's possible for `getCalleeDecl()` to return a null pointer.

This was encountered by a user of our downstream compiler.

The case involved a DependentScopeDeclRefExpr.

Since this seems to only be for a warning diagnostic, I skipped
the diagnostic check if it returned null. But mabye there's a
different way to fix this.

[X86] Remove unreachable code in X86TargetTransformInfo.cpp

In Function getVectorInstrCost, situation Opcode == Instruction::ExtractElement
and Opcode == Instruction::InsertElement are all handled in the first 2 if-statements,
So we have no chance for the code in line 4401.

Reviewed By: RKSimon

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

[libcxx] Add status paper for Parallelism-TS

Reviewed By: #libc, philnik, Mordante

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

Attributor: Start inferring nofpclass

Some of this is boilerplate which doesn't do anything yet.

ValueTracking: Extract fcmpToClassTest out of InstCombine

Also update unsigned to FPClassTest

ValueTracking: Handle nofpclass in computeKnownFPClass

ValueTracking: Add start of computeKnownFPClass API

Add a new compute-known-bits like function to compute all
the interesting floating point properties at once.

Eventually this should absorb all the various floating point
queries we already have.

Revert "[Sema] Fix null pointer dereference handleAlwaysInlineAttr."

This reverts commit 10297470e953f4f3968c54c851c8af82b07af00b.

This is failing on a build bot.

[RISCV] Add MULW to RISCVStripWSuffix.

This converts MULW to MUL if the upper bits aren't used.
This will give more opportunities to use c.mul with Zcb.

Revert "[LSAN][HWASAN] Turn on leak sanitizer in HWASAN for Linux"

Breaks x86_64 qemu tests.

This reverts commit 6c756486d44914bac6fb20513b8c41f1a5726c4c.

Revert "[AMDGPUUnifyDivergentExitNodes] Add NewPM support"

Introduces nullptr dereference.

This reverts commit a5455e32b364dabe499ec11722626d4bbaf047ba.

[libc][Obvious] Reduce the size of the tests for hypot(f).

[Sema] Fix null pointer dereference handleAlwaysInlineAttr.

It's possible for `getCalleeDecl()` to return a null pointer.

This was encountered by a user of our downstream compiler.

The case involved a DependentScopeDeclRefExpr.

Since this seems to only be for a warning diagnostic, I skipped
the diagnostic check if it returned null. But mabye there's a
different way to fix this.

Reviewed By: erichkeane

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

[runtimes] Synchronize warnings flags between libc++/libc++abi/libunwind

This mostly keeps the same warning flags. The most important exceptions are `-Wpedantic` and `-Wconversion`, which are now removed from libc++abi and libunwind.

Reviewed By: ldionne, #libunwind, #libc, #libc_abi

Spies: mikhail.ramalho, phosek, libcxx-commits

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

Remove #if guards from AppendBounds to fix compile on old POSIX.

[AMDGPU] Simplify AGPR reservation. NFC.

The intent of the code was to reserve all AGPRs on a target without
AGPRs, so just do exactly that. Existing code was unsound.

[mlir][transform] change RaggedArray internals

Change the internal storage scheme from storing a MutableArrayRef to
storing an explicit offset+length pair. Storing an ArrayRef is dangerous
because it contains the pointer to the first element in the range, but
the entire storage vector may be reallocated, making the pointer
dangling. We don't know when the reallocation happends, so we can't
update the ArrayRefs. Store the explicit offset instead and construct
ArrayRefs on-the-fly.

Reviewed By: Peiming

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

[TableGen] Fix test on macOS

macOS cmp requires the option to appear before the file names.

[clang] Unconditionally add autolink hints for frameworks.

Clang infers framework autolink hints when parsing a modulemap. In order to do
so, it checks if the module is a framework and if there is a framework binary
or TBD file in the SDK. Only when Clang finds the filei, then the autolink hint
is added to the module metadata.

During a project build many clang processes perform this check, which causes
many stat calls - even for modules/frameworks that are not even used.

The linker is already resilient to non-existing framework links that come from
the autolink metadata, so there is no need for Clang to do this check.

Instead the autolink hints are now added unconditionally and the linker only
needs to do the check once. This reduces the overall number of stat calls.

This fixes rdar://106578342.

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

[lldb] Make MemoryCache::Read more resilient

MemoryCache::Read is not resilient to partial reads when reading memory
chunks less than or equal in size to L2 cache lines. There have been
attempts in the past to fix this but nothing really solved the root of
the issue.

I first created a test exercising MemoryCache's implementation and
documenting how I believe MemoryCache::Read should behave. I then
rewrote the implementation of MemoryCache::Read as needed to make sure
that the different scenarios behaved correctly.

rdar://105407095

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

[RISCV] Remove ExtName from RISCVExtensionInfo.

This field is never used in the compiler and was only used in
unit tests added recently.

It's only used as the value in a map where the extension name
is the key. If we need the string we can get it from the key.

Reviewed By: asb

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

Mark test added in D145155 as requiring asserts since it uses the "-debug-only" option.

This should fix the test failure in Release builds.

[mlir][StorageUniquer] Use allocators per thread instead of per shard

This greatly reduces the number of allocators we create, while still
retaining thread safety. Reducing the number of allocators is much
better for locality and memory usage; this revision drops memory
usage for some MLIR heavy workloads (with lots of attributes/types)
by >=5%. This is due to the observation that the number of threads
is effectively always smaller than the number of parametric attributes/types.

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

[Inliner] clang-format InlineCost.cpp and Inliner.cpp (NFC)

[HWASAN] Remove RUN statements, which have to effect on the test

[LSR] Add tests which demonstrate miscompiles in the current term-fold code

[DAE] Don't DAE if we musttail call a "live" (non-DAE-able) function

There are 2 such base cases: indirect calls and calls to functions external
to the module; and then any musttail calls to live functions (because of
the first 2 reasons or otherwise).

The IR validator reports, in these cases, that it "cannot guarantee tail
call due to mismatched parameter counts".

The fix is two-fold: first, we mark as "live" (i.e. non-DAE-able)
functions that make an indirect musttail call.

Then, we propagate live-ness to musttail callers of live functions.

Declared functions are already marked "live".

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

[SPIRV] fix several issues in builds with expensive checks

The patch fixes "Virtual register does not match instruction constraint"
and partly "Illegal virtual register for instruction" fails in the SPIRV
backend builds with LLVM_ENABLE_EXPENSIVE_CHECKS enabled. As a result,
the number of passed LIT tests with enabled checks is doubled.

Also, support for ndrange_*D builtins is placed in a separate function.

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

[mlir][sparse] add new sparisification option for dependent index reduction-based codegen

Reviewed By: aartbik

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

[mlir][sparse] add a coo slices matmul integration test.

Reviewed By: wrengr

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

[mlir] Fix a warning

This patch fixes:

  mlir/lib/Dialect/Linalg/TransformOps/LinalgTransformOps.cpp:479:13:
  error: unused variable 'tiledOp' [-Werror,-Wunused-variable]

[AIX] unset bit "IsBackChainStored" of traceback table for leaf functions with no stack frame

Summary:

  In function PPCAIXAsmPrinter::emitTracebackTable() ,the bit "IsBackChainStored" of traceback
table always set true, it will cause aix debug tools "dbx" emit an error info
"libdebug assertion "(framep->getGpr(STKP, &addr) == DB_SUCCESS && *nextStkpp == addr)"
when debug a leaf functions with no stack frame.

If a a leaf functions with no stack frame , the bit IsBackChainStored should be unset.

Reviewers: ChenZheng
Differential Revision: https://reviews.llvm.org/D146071

[libc] [test] Add missing <cstdint> include

Fixes build w/ GCC 13:
```
[587/7274] Building CXX object projects/libc/test/src/__support/CMakeFiles/libc_system_str_to_float_comparison_test.dir/str_to_float_comparison_test.cpp.o
FAILED: projects/libc/test/src/__support/CMakeFiles/libc_system_str_to_float_comparison_test.dir/str_to_float_comparison_test.cpp.o
/usr/lib/llvm/16/bin/clang++ -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/sam/git/llvm-project/build/projects/libc/test/src/__support -I/home/sam/git/llvm-project/libc/test/src/__support -I/home/sam/git/llvm-project/build/include -I/home/sam/git/llvm-project/llvm/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -std=c++17 -MD -MT projects/libc/test/src/__support/CMakeFiles/libc_system_str_to_float_comparison_test.dir/str_to_float_comparison_test.cpp.o -MF projects/libc/test/src/__support/CMakeFiles/libc_system_str_to_float_comparison_test.dir/str_to_float_comparison_test.cpp.o.d -o projects/libc/test/src/__support/CMakeFiles/libc_system_str_to_float_comparison_test.dir/str_to_float_comparison_test.cpp.o -c /home/sam/git/llvm-project/libc/test/src/__support/str_to_float_comparison_test.cpp
/home/sam/git/llvm-project/libc/test/src/__support/str_to_float_comparison_test.cpp:34:15: error: unknown type name 'uint32_t'
static inline uint32_t hexCharToU32(char in) {
              ^
/home/sam/git/llvm-project/libc/test/src/__support/str_to_float_comparison_test.cpp:39:15: error: unknown type name 'uint32_t'
static inline uint32_t fastHexToU32(const char *inStr) {
              ^
```

Reviewed By: michaelrj

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

[Driver] Allow to collect `-save-stats` data to a file specified in the environment variable.

Using two environment variables `CC_PRINT_INTERNAL_STAT` and
`CC_PRINT_INTERNAL_STAT_FILE` to work like `CC_PRINT_PROC_STAT`.

The purpose of the change is to allow collecting the internal stats
without modifying the build scripts. Write all stats to a single file
to simplify aggregating the data.

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

[DebugInfo][SROA] Correct debug info for global variables spanning multiple fragments in case of SROA

The function transferSRADebugInfo is modified to include missing cases.

Reviewed By: aprantl

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

[scudo] Test ScudoReleaseTest.BufferPool with a buffer pool allocated on the heap

The previous code resulted in 252 KiB being allocated on the stack,
which caused a stack overflow on Fuchsia.

Reviewed By: Chia-hungDuan

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

Fix asan error uncovered after landing D145133.

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

Fix LLVM Sphinx build

This addresses the issue found by:
https://lab.llvm.org/buildbot/#/builders/30/builds/33006

[HWASAN] Disable leak checking for forced_unwind2.pass.cpp

[InstCombine] Add constant combines for `(urem/srem (mul X, Y), (mul X, Z))`

We can handle the following cases + some `nsw`/`nuw` flags:

`(srem (mul X, Y), (mul X, Z))`
    [If `srem(Y, Z) == 0`]
        -> 0
            - https://alive2.llvm.org/ce/z/PW4XZ-
    [If `srem(Y, Z) == Y`]
        -> `(mul nuw nsw X, Y)`
            - https://alive2.llvm.org/ce/z/DQe9Ek
        -> `(mul nsw X, Y)`
            - https://alive2.llvm.org/ce/z/Nr_MdH

    [If `Y`/`Z` are constant]
        -> `(mul/shl nuw nsw X, (srem Y, Z))`
            - https://alive2.llvm.org/ce/z/ccTFj2
            - https://alive2.llvm.org/ce/z/i_UQ5A
        -> `(mul/shl nsw X, (srem Y, Z))`
            - https://alive2.llvm.org/ce/z/mQKc63
            - https://alive2.llvm.org/ce/z/uERkKH

`(urem (mul X, Y), (mul X, Z))`
    [If `urem(Y, Z) == 0`]
        -> 0
            - https://alive2.llvm.org/ce/z/LL7UVR
    [If `srem(Y, Z) == Y`]
        -> `(mul nuw nsw X, Y)`
            - https://alive2.llvm.org/ce/z/9Kgs_i
        -> `(mul nuw X, Y)`
            - https://alive2.llvm.org/ce/z/ow9i8u

    [If `Y`/`Z` are constant]
        -> `(mul nuw nsw X, (srem Y, Z))`
            - https://alive2.llvm.org/ce/z/mNnQqJ
            - https://alive2.llvm.org/ce/z/Bj_DR-
            - https://alive2.llvm.org/ce/z/X6ZEtQ
        -> `(mul nuw X, (srem Y, Z))`
            - https://alive2.llvm.org/ce/z/SJYtUV

The rationale for doing this all in `InstCombine` rather than handling
the constant `mul` cases in `InstSimplify` is we often create a new
instruction because we are able to deduce more `nsw`/`nuw` flags than
the original instruction had.

Reviewed By: MattDevereau, sdesmalen

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

[InstCombine] Add tests for combining (urem/srem (mul/shl X, Y), (mul/shl X, Z)); NFC

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

[NFC][libc++] Formats granularized charconv.

Reviewed By: #libc, Mordante

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

[libc][Obvious] Remove the STARTUP attribute from the api test listing.

[docs] Mention removal of legacy optimization pipeline and inliner alloca merging

Reviewed By: asbirlea

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

[NFC][ADT] Tweaked some functions in StringRef

Reduced the usage of variables in the `rfind` and `count` functions.

Replaced calls to `drop_front` with direct use of `substr` in `consume_front`,
since `starts_with` already performs length check on the string. Did the same
for other functions.

Using the `std::clamp` in `slice` makes the code more straightforward.

Reviewed By: bkramer

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

[libc] Remove unused startup source file

Summary:
This was not removed from the previous patch. Fix that.

[HWASAN] Disable leak checking for test_vector2.pass.cpp

[libc] Remove startup option from integration tests

This generalizes handling of the integration tests. We now implicitly
depend on the `libc.startup.${LIBC_TARGET_OS}.crt1` file rather than
passing it in manually. This simplifies the interface.

Reviewed By: sivachandra

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

[TTI] Add X86 target specific version of getPointersChainCost.

When all the pointers are off the same base address and have known
distances to each other these differences can be encoded into displacements
in x86 arch. So the only cost that matters is cost of the base GEP.

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

[AMDGPU] Select flat atomic fmin/fmax

Also disables global atomic fmin/fmax x2 patterns on gfx11

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

[VPlan] Consolidate replicate region optimizations (NFC).

As suggested in D143865, consolidate replicate region creation and
optimization in a single helper that's exposed and used by LV.

[Inliner] Remove alloca merging

See https://discourse.llvm.org/t/rfc-we-should-stop-merging-allocas-in-the-inliner/41975 for the RFC from 2016 around this.

Backend stack coloring takes care of what this initially set out to help with.

This only affects the legacy inliner, which for the most part doesn't matter anymore. The new PM inliner never looked at this flag.

There are some backends running the legacy always-inline pass, but that's unlikely to matter.

Reviewed By: asbirlea

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

[opt] Rename -enable-new-pm -> -bugpoint-enable-legacy-pm

-enable-new-pm is no longer necessary except for bugpoint. Make the name more clunky so it hopefully won't be used.

Reviewed By: nikic

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

[Debugify] Use ModuleAnalysisManager in instrumentation

In preparation for doing module checks of PreservedAnalyses.

workflows: Don't try and run llvm-bugs in forks

Most forks won't have an LLVM_BUGS_KEY secret, so Mailgun will error out
with a missing key, and if forks do happen to have such a secret then we
still don't want to be getting emails to LLVM's mailing lists for
downstream forks.

Reviewed By: tstellar

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