If `__first == __middle`, then `partial_sort` is a no-op; don't
bother to iterate all the way from `__middle` to `__end`.
Fixes#49431.
Differential Revision: https://reviews.llvm.org/D116296
617007240cbfb97c introduced the use of ActOnDependentMemberExpr with
variable template specialization. The assertion inside
ActOnDependentMemberExpr should be adjusted accordingly.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47211
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D113146
Unsigned compares work with either zero extended or sign extended
inputs just like equality comparisons. I didn't allow this when
I refactored the code in D116421 due to lack of tests. But I've
since found a simple C test case that demonstrates when this can be
useful.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D116617
If there are multiple uses of the def of COPY/REG_SEQUENCE, set the
latency only if the latencies on all the uses are equal, otherwise set
it to default.
D111404 moved a 4/8 byte check assert into a block taken by 2-byte platforms.
Since these platforms do not take the branches where the pointer size is used,
sink the assert accordingly.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D116480
The HexagonVectorCombine pass was moving an instruction
incorrectly, which caused a use in a GEP that was not yet
defined.
HexagonVectorCombine removes a load from a group due to its
dependences, but in realignGroup, the load is processed anyways.
In realignGroup, when determining the maximum alignment, only
those instructions still in the group should be considered.
AFAICT, Cpp17InputIterators are not required to be default constructible,
since that requirement is added in Cpp17ForwardIterator. Hence, our
archetype for Cpp17InputIterator should not be default constructible.
Removing that constructor has a ripple effect on a couple of tests that
were making incorrect assumptions. Notably:
- Some tests were using cpp17_input_iterator as a sentinel for itself.
That is not valid, because a cpp17_input_iterator is not semiregular
anymore after the change (and hence it doesn't satisfy sentinel_for).
- Some tests were using a stride-counted cpp17_input_iterator as the
sentinel for a range. This doesn't work anymore because of the problem
above, so these tests were changed not to check stride counts for
input iterators.
- Some tests were default constructing cpp17_input_iterator when a simple
alternative was available -- those have been changed to use that alternative.
Differential Revision: https://reviews.llvm.org/D115806
I considered multiple approaches for this but settled on this one because I could make the lifetime management work in a reasonably easy way (others had issues with not being able to cast to a Python reference from a C++ constructor). We could stand to have more formatting helpers, but best to get the core mechanism in first.
Differential Revision: https://reviews.llvm.org/D116568
Some headers which require the version header depend on other headers to
provide it. Include the version header in all top-level headers to make
sure a header cleanup can't remove the version header.
Note this doesn't add the version header to the c headers.
Reviewed By: #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D116172
Use the zx_cprng_draw system call directly rather than going
through the libc getentropy function. The libc function is a
trivial wrapper around the system call, and is not a standard C
function. Avoiding it reduces the Fuchsia libc ABI surface that
libc++ depends on.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D116498
This was noted in post-commit review for D116322 / 0edf99950e6 .
I am not seeing how to expose the bug in a test though because
we don't pass an assumption cache into this analysis from there.
Previously we only recognized strided loads/store when the initial
value for the phi was a strided constant vector.
This patch extends the support to a strided_constant added to a
splatted value. The rewritten loop will add the splat value to the
first element of the strided constant vector to use as the scalar
start value. The stride is unaffected.
Reviewed By: frasercrmck
Differential Revision: https://reviews.llvm.org/D115958
The Vector Constant Evaluator assumes that all the types of its
sub-expressions are going to be Vector APValues, which holds for most
situations. However, in the 1 examples of Altivec C compilation of
operator ++ (not allowed for other vector types), the result is an
LValue.
Since the operator isn't supported for constant evaluation anyway, this
patch just fails-out of constant eval if we are in a situation where the
operand to the unary operator causes an LValue.
This ports the logic we generate in instcombine for a single use x.with.overflow check for use in SCEV's analysis. The result is that we can prove trip counts for many checks, and (through existing logic) often discharge them.
Motivation comes from compiling a simple example with -ftrapv.
Differential Revision: https://reviews.llvm.org/D116499
When cross-compiling, in order to make the output of the native and
cross-compiled llvm-config match, one needs to re-pass all cmake flags
relevant to BuildVariables.inc via `CROSS_TOOLCHAIN_FLAGS_NATIVE`. If
`LLVM_LINK_LLVM_DYLIB=ON` is among those, building a full `libLLVM` shared
object is required for the native llvm-config, otherwise `--shared-mode`
will be incorrect and `--link-shared` broken.
To avoid this, we can make llvm-config link statically against the
needed components for simplicity's sake in both the native and cross
case.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D116537
This builds on the code from D114963, and extends it to handle calls both direct and indirect. With the revised code structure (from series of previously landed NFCs), this is pretty straight forward.
One thing to note is that we can not infer writeonly for arguments which might be captured. If the pointer can be read back by the caller, and then read through, we have no way to track that. This is the same restriction we have for readonly, except that we get no mileage out of the "callee can be readonly" exception since a writeonly param on a readonly function is either a) readnone or b) UB. This means we can't actually infer much unless nocapture has already been inferred.
Differential Revision: https://reviews.llvm.org/D115003
SelectionDAG::getConstant creates an APInt internally anyway, and getLowBitsSet helps assert for legal bitwidths. Plus it silences static analyzer out-of-bounds shift warnings.
Previously it would not consider ops with
DeclareOpInterfaceMethods<InferTypeOpInterface> as having the
InferTypeOpInterface interfaces added. The OpInterface nested inside
DeclareOpInterfaceMethods is not retained so that one could query it, so
check for the the C++ class directly (a bit raw/low level - will be
addressed in follow up).
Differential Revision: https://reviews.llvm.org/D116572
This change adds an option AfterOverloadedOperator in SpaceBeforeParensOptions to add a space between overloaded operator and opening parentheses in clang-format.
Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D116283
We need to reuse them for the ML regalloc eviction advisor, as we
'explode' the weight calculation into sub-features.
Differential Revision: https://reviews.llvm.org/D116074
This was suggested in D114831. It should simplify the relation between
eviction advisor and the allocator, and simplify ingesting more features
tied to the internals of the allocator, in the future.
This change simply pulls out RAGreedy, places it in the llvm namespace,
and cleans up a bit the includes in the new header file.
Differential Revision: https://reviews.llvm.org/D116114
All of these functions would be `readnone`, but can't be on platforms
where they can set `errno`. A `writeonly` function with no pointer
arguments can only write (but never read) global state.
Writeonly theoretically allows these calls to be CSE'd (a writeonly call
with the same arguments will always result in the same global stores) or
hoisted out of loops, but that's not implemented currently.
There are a few functions in this list that could be `readnone` instead
of `writeonly`, if someone is interested.
Differential Revision: https://reviews.llvm.org/D116426
There are some duplicate test lines in clang/test/Driver/arm-cortex-cpus.c.
Looks like these were duplicated from the corresponding v8.0a tests, which test
both "-target armv8" and "-target armv8a". "-target armv8.X" without the "a"
doesn't work for later versions though.
Several tests also specify the -mlittle-endian twice, which looks unintentional.
Remove duplicate test: -target arm -march=armv5 -mthumb
Differential Revision: https://reviews.llvm.org/D116415
0a00d64 turned an early exit here into an assertion, but the assertion
can be triggered, as PR52920 shows.
The later code is agnostic to the accessed type, so just drop the
assert. The patch also adds tests for LAA directly and
loop-load-elimination to show the behavior is sane.
It's reasonable to want to use the command from one file to compile another.
In particular, the command from a translation unit to parse a related header:
{"file": "foo.h", "command": "clang foo.cpp"}
This is largely what InterpolatingCompilationDatabase tries to do.
To do this correctly can require nontrivial changes to the argv, because the
file extension affects semantics. e.g. here we must add "-x c++header".
When external tools compile commands for different files, we should apply the
same adjustments. This is better than telling people to "fix their tools":
- simple e.g. python scripts shouldn't have to interpret clang argv
- this is a good way to represent the intent "parse header X in the context of
file Y", which can work even if X is not self-contained. clangd does not
support this today, but some other tools do, and we may one day.
This issue is discussed in https://github.com/clangd/clangd/issues/519
Differential Revision: https://reviews.llvm.org/D116167
This folded (null + X) == g to false, but of course this is
incorrect if X == g.
Possibly this got confused with the null == g case, which is
already handled elsewhere.
This is now testing (null + g3) != g3 and still coming up with
"true" as the answer. The original case was a less obvious
miscompile with index overflow involved.
The "parameter list" is the list of fields which should be initialized.
We introduce a new OverloadCandidate kind for this.
It starts to become harder for CC consumers to handle all the cases for
params, so I added some extra APIs on OverloadCandidate to abstract them.
Includes some basic support for designated initializers.
The same aggregate signature is shown, the current arg jumps after the
one you just initialized. This follows C99 semantics for mixed
designated/positional initializers (which clang supports in C++ as an extension)
and is also a useful prompt for C++ as C++ designated initializers must be
in order.
Related bugs:
- https://github.com/clangd/clangd/issues/965
- https://github.com/clangd/clangd/issues/306
Differential Revision: https://reviews.llvm.org/D116326
This patch makes jitlink to report an out of range error when the fixup value out of range
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D107328
This class is solely used as a lightweight and clean way to build a set of
attributes to be removed from an AttrBuilder. Previously AttrBuilder was used
both for building and removing, which introduced odd situation like creation of
Attribute with dummy value because the only relevant part was the attribute
kind.
Differential Revision: https://reviews.llvm.org/D116110
