Cases where there is a mangling of a cpu-dispatch/cpu-specific function
before the function becomes 'multiversion' (such as a member function)
causes the wrong name to be emitted for one of the variants/resolver,
since the name is cached.  Make sure we invalidate the cache in
cpu-dispatch/cpu-specific modes, like we previously did for just target
multiversioning.

Force semicolons or remove them in `experimental/simd`

Reviewed By: Quuxplusone, ldionne, Mordante, #libc

Spies: libcxx-commits, miyuki

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

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

The transform replaces one icmp with another, so we should
not care if the shift has another use.

I believe all four of these failures are directly due to the pattern where
allocations in the dylib are unobserved by the client program. If AIX32 and AIX64
don't support that, we should just disable the ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS
macro on AIX, and then we don't need to XFAIL these tests.

This also means I won't need to XFAIL a dozen other tests in D89057,
which rely heavily on ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS and
also currently fail on AIX.
See https://buildkite.com/llvm-project/libcxx-ci/builds/7669

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

Implement log2f based on RLIBM library correctly rounded for all rounding modes.

Reviewed By: sivachandra, michaelrj, santoshn, jpl169, zimmermann6

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

- Generic visitors invoke operation callbacks before/in-between/after visiting the regions
  attached to an operation and use a `WalkStage` to indicate which regions have been
  visited.
- This can be useful for cases where we need to visit the operation in between visiting
  regions attached to the operation.

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

Generalize 57a551a8 - if the inlane mask is a repeated mask, we're better off performing the lane permute instead of splitting

Specifically the unary shuffle case where the elements being
shifted in are undef. This handles the shuffles produce by expanding
llvm.reduce.mul.

I did not reduce the VL which would increase the number of vsetvlis,
but may improve the execution speed. We'd also want to narrow the
multiplies so we could share vsetvlis between the vslidedown.vi and
the next multiply.

Reviewed By: frasercrmck

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

[RISCV] Honor the VT when converting float point register names to register class for inline assembly.

It appears the code here was written for the inline asm clobbering
a specific register, but it also gets used for named input and
output registers.

For the input and output case, we should honor the VT so we
don't insert conversion instructions around the inline assembly.

For the clobber, case we need to pick the largest register class.

Reviewed By: asb, jrtc27

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

Hopefully fixes the build failure. Also fix a typo.

I'm not entirely sure, but based on how ComputeNumSignBits handles
ISD::MUL, I believe this code was miscounting the number of sign
bits.

As an example of an incorrect result let's say that countMinSignBits
returned 1 for the left hand side and 24 for the right hand side.
LHSValBits would be 23 and RHSValBits would be 0 and the sum would
be 23. This would cause the code to set 9 high bits as zero/one. Now
suppose the real values for the left side is 0x800000 and the right
hand side is 0xffffff. The product is 0x00800000 which has 8 sign bits
not 9.

The number of valid bits for the left and right operands is now
the number of non-sign bits + 1. If the sum of the valid bits of
the left and right sides exceeds 32, then the result may overflow and we
can't say anything about the sign of the result. If the sum is 32
or less then it won't overflow and we know the result has at least
1 sign bit.

For the previous example, the code will now calculate the left
side valid bits as 24 and the right side as 1. The sum will be 25
and the sign bits will be 32 - 25 + 1 which is 8, the correct value.

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

The multiply in this test is miscompiled to 0.

Reviewed By: foad

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

Goes with D117110.

The tests above this were added for D30781 and used to provide
coverage for a limit of knownbits, but improvements in other
transforms killed that intended purpose. This was noted because
another proposed improvement in D117110 will further reduce
those tests.

Mention -opaque-pointers, write a bit more about migration pitfalls
and update the open issues.

The aim of this patch is to break up the larger patch (https://reviews.llvm.org/D111323) to be more upstream friendly. In particular, this patch adds the char encoding sensitive changes but does not use inline namespaces as before. The use of namespaces to build both versions of the library, and localization of error messages will follow in a subsequent patch.

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

This reverts commit 83338d50.  Comments in source are non-idiomatic and naming choice in head is unclear.

[LTO] runNewPMPasses - remove check for TM != nullptr as we already dereference the pointer directly later on in the same code

Please see
https://github.com/flang-compiler/f18-llvm-project/issues/1344#issuecomment-1012706527
for context and the discussion.

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

Reduced test case from the reproducer mentioned in
073c27b5.

[llvm-profgen] ProfiledBinary::load - use cast<> instead of dyn_cast<> to avoid dereference of nullptr

The pointer is always dereferenced immediately, so assert the cast is correct instead of returning nullptr

Also fix a memory leak in the test while at it.

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

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.

Reviewed-by: ymandel, xazax.hun

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

I didn't split the calendar bits more than this because there was little
benefit to doing it, and I know our calendar support is incomplete.
Whoever picks up the missing calendar bits can organize these headers
at their leisure.

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

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