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
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](fa0118e6e5).
Originally contributed by Ahmed Mahdy (@aybassiouny). Thank you!
Reviewed By: Wawha, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D99031
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
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 e734e8286b, 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
This reverts the revert commit 073c27b5e5.
A reduced test case has been added in 5e4966cbae 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
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
- 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
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
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
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 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.
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
Marek Kurdej