Changes

Factor out renaming logic from readability-identifier-naming
Before this patch, readability-identifier-naming contained a significant
amount of logic for (a) checking the style of identifiers, followed by
(b) renaming/ applying fix-its. This patch factors out (b) into a
separate base class so that it can be reused by other checks that want
to do renaming. This also cleans up readability-identifier-naming
significantly, since now it only needs to be concerned with the
interesting details of (a).

[gn build] Port d5c6b8407c1

[OPENMP]Avoid string concat where possible and use standard name
generation function, NFC.

[IR] fix crash in Constant::isElementWiseEqual() with FP types
We lifted this code from InstCombine for general usage in: rL369842
...but it's not safe as-is. There are no existing users that can trigger
this bug, but I discovered it via crashing several regression tests when
trying to use it for select folding in InstSimplify.
ICmp requires (vector) integer types, so give up on anything that's not
integer or FP (pointers and ?) then bitcast the constants before trying
the match. That matches the definition of "equal or undef" that I was
looking for. If someone wants an FP-aware version of equality (deal with
NaN, -0.0), that could be a different mode or different function.
Differential Revision: https://reviews.llvm.org/D72784

[WebAssembly] Track frame registers through VReg and local allocation
This change has 2 components:
Target-independent: add a method getDwarfFrameBase to
TargetFrameLowering. It describes how the Dwarf frame base will be
encoded.  That can be a register (the default), the CFA (which replaces
NVPTX-specific logic in DwarfCompileUnit), or a DW_OP_WASM_location
descriptr.
WebAssembly: Allow WebAssemblyFunctionInfo::getFrameRegister to return
the correct virtual register instead of FP32/SP32 after
WebAssemblyReplacePhysRegs has run.  Make WebAssemblyExplicitLocals
store the local it allocates for the frame register. Use this local
information to implement getDwarfFrameBase
The result is that the DW_AT_frame_base attribute is correctly encoded
for each subprogram, and each param and local variable has a correct
DW_AT_location that uses DW_OP_fbreg to refer to the frame base.
Differential Revision: https://reviews.llvm.org/D71681

Add BuiltinsHexagonDep.def to clang module map

[llvm-nm] Use `StringRef` over `const std::string &` params
Differential Revision: https://reviews.llvm.org/D72718

AMDGPU: Move permlane discard vdst_in optimization
This case can be handled as a regular selection pattern, so move it out
of the weird post-isel folding code which doesn't have an exactly 
equivalent place in GlobalISel.
I think it doesn't make much sense to do this optimization here though,
and it would be more useful in instcombine. There's not really any new
information that will be gained during lowering since these inputs were
known from the beginning.

AMDGPU: Do permlane16 vdst_in discard optimization in InstCombine
There's more potential value to discarding the source value earlier, 
since we always know the value of the fi/bc bits.

Revert "[WebAssembly] Track frame registers through VReg and local
allocation"
This reverts commit 3a05c3969c18b5520e360b78fc63cda39a6be98f. It breaks
under expensive-checks and on Windows

lldb: xfail TestCrossDSOTailCalls.py and TestCrossObjectTailCalls.py on
arm/aarch64
This effectively reverts commit 
8d2f252bb8e4d199be8498c4ee2245117ef08fd2, which went a bit too far and 
disabled these on all non-Darwin systems.

[libcxx] Temporarily switch back to pthread backend for Fuchsia
We switched to C11 thread API on Fuchsia in ab9aefe, but further testing
showed that Fuchsia's C11 mutex implementation needs a few improvements
for this to be usable, so we temporarily switch back to the pthread
implementation until those issues are addressed.
Differential Revision: https://reviews.llvm.org/D72862

[lld][WebAssembly] Use a more meaningful name for stub functions
When we generate these stub functions on signature mismatches give them
a more meaningful name so that when people see this in stack traces is
gives a clue as the what is going on.
See: https://github.com/emscripten-core/emscripten/issues/10226
Differential Revision: https://reviews.llvm.org/D72881

[mlir] NFC: Fix trivial typos
Summary: Fix trivial typos
Differential Revision: https://reviews.llvm.org/D72672

[mlir] support translation of multidimensional vectors to LLVM IR
Summary: MLIR unlike LLVM IR supports multidimensional vector types.
Such types are lowered to nested LLVM IR arrays wrapping an LLVM IR
vector for the innermost dimension of the MLIR vector. MLIR supports
constants of such types using ElementsAttr for values. Introduce support
for converting ElementsAttr into LLVM IR Constant Aggregates
recursively. This enables translation of multidimensional vector
constants from MLIR to LLVM IR.
Differential Revision: https://reviews.llvm.org/D72846

[clangd][test] Disable a particular testcase in
FindExplicitReferencesTest when LLVM_ENABLE_EXPENSIVE_CHECKS
The test is failing on our CI bots. Seems like the order of results for
one target is undefined.
(post-commit review) Differential Revision:
https://reviews.llvm.org/D72883

AMDGPU: Update clang test

[OPENMP]Do not emit RTTI descriptor for NVPTX devices.
Need to disable emission of RTTI descriptors for NVPTX devices to be 
able to use dynamic classes without unresolved symbols at link stage.

[AArch64][GlobalISel] Change G_FCONSTANTs feeding into stores into
G_CONSTANTS
Given the following situation:
x = G_FCONSTANT (something that can't be materialized) G_STORE x,
some_addr
We know that x must be materialized as at least a single mov. However,
at the time of selection, the G_STORE will have been regbankselected to
a FPR store.
So, as a result, you'll get an unnecessary fmov into the G_STORE.
Storing a constant value in a GPR and a constant value in a FPR are the
same. So, whenever you see a G_FCONSTANT that feeds into only G_STORES,
so might as well make it a G_CONSTANT.
This adds a target-specific combine which changes G_FCONSTANTs feeding
into G_STOREs into G_CONSTANTs.
Differential Revision: https://reviews.llvm.org/D72814