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

With config:
```
AllowShortFunctionsOnASingleLine: Inline
NamespaceIndentation: All
```

The code:
```
namespace Test
{
    void f()
    {
        return;
    }
}
```
was incorrectly formatted to:
```
namespace Test
{
    void f() { return; }
}
```

since the function `f` was considered being inside a class/struct/record.
That's because the check was simplistic and only checked for a non-zero indentation level of the line starting `f`.

Reviewed By: MyDeveloperDay, HazardyKnusperkeks

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

This seems to be a leftover from a long time ago when there was
an ISD::VBIT_CONVERT and a MVT::Vector. It looks like in those days
the vector type was carried in a VTSDNode.

As far as I know, these days ComputeValueTypes would have already
assigned "Result" the same type we're getting from TLI.getValueType
here. Thus the BITCAST is always a NOP. Verified by adding an assert
and running check-llvm.

Reviewed By: efriedma

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

Merge nasty_macros.h into the new test.

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

[clang-format] Fix CompactNamespaces corner case when AllowShortLambdasOnASingleLine/BraceWrapping.BeforeLambdaBody are set

In clang-format 12, `CompactNamespaces` misformatted the code when `AllowShortLambdasOnASingleLine` is set to false and `BraceWrapping.BeforeLambdaBody` is true.

Input:
```
namespace out {
namespace in {
}
} // namespace out::in
```

Expected output:
```
namespace out { namespace in {
}} // namespace out::in
```

Output from v12:
```
namespace out {
namespace in {
}
} // namespace out::in
```

Config triggering the issue:
```
---
AllowShortLambdasOnASingleLine: None
BraceWrapping:
  BeforeLambdaBody :    true
BreakBeforeBraces: Custom
CompactNamespaces: true
...
```

Seems there's a corner case when `AllowShortLambdasOnASingleLine` is false, and `BraceWrapping.BeforeLambdaBody` is true, that causes CompactNamespaces to stop working.
The cause was a misannotation of `{` opening brace after `namespace` as a lambda opening brace.
The regression was probably introduced with [this commit](https://github.com/llvm/llvm-project/commit/fa0118e6e588fe303b08e7e06ba28ac1f8d50c68).

Originally contributed by Ahmed Mahdy (@aybassiouny). Thank you!

Reviewed By: Wawha, HazardyKnusperkeks

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

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

Allocation functions should be marked with onlyAccessesInaccessibleMemory (when that is correct for the given function) which is checked elsewhere so this check is no longer needed.

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

To silence modular build error https://reviews.llvm.org/harbormaster/unit/view/1854595/

This patch supported the R_RISCV_BRANCH relocation.

Reviewed By: lhames

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

Existing code tended to assume that counters had type `uint64_t` and
computed size from the number of counters. Fix this code to directly
compute the counters size in number of bytes where possible. When the
number of counters is needed, use `__llvm_profile_counter_entry_size()`
or `getCounterTypeSize()`. In a later diff these functions will depend
on the profile mode.

Change the meaning of `DataSize` and `CountersSize` to make them more clear.
* `DataSize` (`CountersSize`) - the size of the data (counter) section in bytes.
* `NumData` (`NumCounters`) - the number of data (counter) entries.

Reviewed By: kyulee

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

After e734e828, it is possible to end up in
a situation where an `indirectbr` is fed by a cast, which is in turn fed by
an operation which only produces integers.

`indirectbr` expects a block address, however these operations can't produce
that.

There were several asserts in `computeValueKnownInPredecessorsImpl` which check
that we're not looking for a block address if we're walking through something
which can never produce one.

Since it's now possible to hit these asserts, this changes them into actual
checks which return false if `Preference` is not `WantInteger`.

This adds a testcase which verifies that we don't crash anymore in these
situations.

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

Use ASTContext::getTypeDeclType() to get type of omp_interop_t since
TypeDecl::getTypeForDecl() may return null if TypeForDecl is not
setup yet.

Handle functions where the function type is under an AttributedType.

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

Add additional "CFI" types for Fortran REAL and COMPLEX kinds 2, 3, 10, 16 to allow their use in Fortran descriptors.

This reverts the revert commit 073c27b5.

A reduced test case has been added in 5e4966cb and the code has
been updated to handle the case where getInductionOpcode returns
BinaryOpsEnd. In this case, the original code was always using
Instruction::Add. Do the same in the patch.

Note this commit may slightly change the value naming, because it now
also assigns the 'induction' name in the floating point case.

This commit adds new tests that check the patterns that D117252 will
fix. As requested by @spatel.

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

Derived types with SEQUENCE must have data components of sequence
types; but this rule is relaxed as common an extension in the case of
pointer components, whose targets' types are not really relevant
to the implementation requirements of sequence types.

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

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.