Fixes#123524
---
This PR addresses the issue of immediate function expressions not
properly evaluated in `constexpr` if conditions. Adding the
`ConstantEvaluated` context for expressions in `constexpr` if statements
ensures that these expressions are treated as manifestly
constant-evaluated and parsed correctly.
Add a new WebKit checker for checking that lambda captures of CF types
use RetainPtr either when ARC is disabled or enabled, and those of NS
types use RetainPtr when ARC is disabled.
This is to make sure that ADT helpers consistently use argument
dependent lookup when dealing with input ranges.
This was a part of #87936 but reverted due to buildbot failures. Now
that I have a threadripper system, I'm landing this piece-by-piece.
This PR adds scalar/vector overloads for vector conditions to the
`select` builtin, and updates the sema checking and codegen to allow
scalars to extend to vectors.
Fixes#126570
The condition to stop iterating so far was to look for load command cmd
field == 0. The iteration would continue past the commands area, and
would finally find lc->cmd ==0, if lucky. Or crash with bus error, if
out of luck.
Correcting this by limiting the number of iterations to the count
specified in mach_header(_64) ncmds field.
rdar://143903403
---------
Co-authored-by: Mariusz Borsa <m_borsa@apple.com>
Create an empty VPlan first, then let the HCFG builder create a plain
CFG for the top-level loop (w/o a top-level region). The top-level
region is introduced by a separate VPlan-transform. This is instead of
creating the vector loop region before building the VPlan CFG for the
input loop.
This simplifies the HCFG builder (which should probably be renamed) and
moves along the roadmap ('buildLoop') outlined in [1].
As follow-up, I plan to also preserve the exit branches in the initial
VPlan out of the CFG builder, including connections to the exit blocks.
The conversion from plain CFG with potentially multiple exits to a
single entry/exit region will be done as VPlan transform in a follow-up.
This is needed to enable VPlan-based predication. Currently early exit
support relies on building the block-in masks on the original CFG,
because exiting branches and conditions aren't preserved in the VPlan.
So in order to switch to VPlan-based predication, we will have to
preserve them in the initial plain CFG, so the exit conditions are
available explicitly when we convert to single entry/exit regions.
Another follow-up is updating the outer loop handling to also introduce
VPRegionBlocks for nested loops as transform. Currently the existing
logic in the builder will take care of creating VPRegionBlocks for
nested loops, but not the top-level loop.
[1]
https://llvm.org/devmtg/2023-10/slides/techtalks/Hahn-VPlan-StatusUpdateAndRoadmap.pdf
PR: https://github.com/llvm/llvm-project/pull/128419
In https://github.com/llvm/llvm-project/pull/97762, we assume the
minimum possible value of X is NaN implies X is NaN. But it doesn't hold
for x86_fp80 format. If the knownbits of X are
`?'011111111111110'????????????????????????????????????????????????????????????????`,
the minimum possible value of X is NaN/unnormal. However, it can be a
normal value.
Closes https://github.com/llvm/llvm-project/issues/130408.
This PR fixes issue #124815 by correcting the handling of `nullptr` with
`std::unique_ptr` in the `modernize-use-ranges` check.
Updated the logic to suppress warnings for `nullptr` in `std::find`.
Minor tweak to #129363 which handled all the cases where there was a sext for the original source value, but not for cases where the source is already half the size of the destination type
Another regression noticed in #76524
Instructions with relocation `R_LARCH_CALL36` may be relax as follows:
```
From:
pcaddu18i $dest, %call36(foo)
R_LARCH_CALL36, R_LARCH_RELAX
jirl $r, $dest, 0
To:
b/bl foo # bl if r=$ra, b if r=$zero
R_LARCH_B26
```
Changes the handling of:
- llvm.aarch64.neon.smaxv
- llvm.aarch64.neon.sminv
- llvm.aarch64.neon.umaxv
- llvm.aarch64.neon.uminv
- llvm.vector.reduce.smax
- llvm.vector.reduce.smin
- llvm.vector.reduce.umax
- llvm.vector.reduce.umin
- llvm.vector.reduce.fmax
- llvm.vector.reduce.fmin
from the default strict handling (visitInstruction) to
handleVectorReduceIntrinsic.
Also adds a parameter to handleVectorReduceIntrinsic to specify whether
the return type must match the elements of the vector.
Updates the tests from https://github.com/llvm/llvm-project/pull/129741,
https://github.com/llvm/llvm-project/pull/129810,
https://github.com/llvm/llvm-project/pull/129768
- Aligns all version comments to line 65.
- Consistently uses `// since C++` instead of `// C++`, in lowercase as
used in most version comments.
- Consistently uses `class` to introduce type template parameters.
- Consistently uses `inline constexpr` for variable templates.
- Corrects the comment for `bool_constant` to `// since C++17` as it's a
C++17 feature.
- Changes the class-key of `result_of` to `struct`, which follows N4659
[depr.meta.types] and the actual usage in libc++.
- Adds missed `// since C++17` for `is_(nothrow_)invocable(_r)`.
- Moves the comments for `is_nothrow_convertible_v` to the part for
variable templates.
- Removes duplicated comments for `true_type` and `false_type`.
Change the handling of:
- llvm.aarch64.neon.fmaxp
- llvm.aarch64.neon.fminp
- llvm.aarch64.neon.fmaxnmp
- llvm.aarch64.neon.fminnmp
- llvm.aarch64.neon.smaxp
- llvm.aarch64.neon.sminp
- llvm.aarch64.neon.umaxp
- llvm.aarch64.neon.uminp
from the incorrect heuristic handler (maybeHandleSimpleNomemIntrinsic)
to handlePairwiseShadowOrIntrinsic.
Updates the tests from https://github.com/llvm/llvm-project/pull/129760
Adds a note that maybeHandleSimpleNomemIntrinsic may incorrectly match
horizontal/pairwise intrinsics.
This option, under `CompileFlags`, governs whether clangd uses its own
built-in headers (`Clangd` option value) or the built-in headers of the driver
in the file's compile command (`QueryDriver` option value, applicable to
cases where `--query-driver` is used to instruct clangd to ask the driver
for its system include paths).
The default value is `Clangd`, preserving clangd's current defaut behaviour.
Fixesclangd/clangd#2074
