[pull] main from llvm:main - #1727
Merged
Merged
Conversation
…214113) Our enable_warnings=False parameter in the test suite was basically not working as intended. Instead of disabling warnings, it would disable all warning-related flags, including flags that are required for the test suite to pass (e.g. -Wno-user-defined-literals). As a result, it couldn't be turned off. Remove enable_warnings and introduce enable_werror instead. That way, we can disable -Werror in the test suite but the warnings (and -Wno-foo) are always used, which is necessary for the test suite to function. Note that the ability to run the test suite without -Werror is necessary in order to test against other implementations, including older versions of libc++ itself.
We were using GoogleBenchmark's default benchmark_min_time of 0.5s,
which makes the benchmark suite slow to run for little benefit. This
patch adds a benchmark_min_time Lit parameter and defaults it to 0.2s,
which runs the suite over 2x faster. It also bumps the PR benchmark job
from median-of-3 to median-of-5 to make up for the slightly noisier
samples.
To pick the value of 0.2s, every benchmark in the suite was run at 0.5s
and 0.2s back-to-back, 5 times. Over the whole benchmark suite:
```
median CV p90 p99
0.5s 0.40% 2.34% 16.93%
0.2s 0.53% 2.45% 17.03%
```
So while 0.2s is noisier, the noise increase sits mostly in the body of
the distribution instead of the tail. The tail of noisier benchmarks is
where the noise is already a problem for detecting regressions, but this
change doesn't have a large impact on that. I think that addressing
those noisy benchmarks directly (by e.g. rewriting or finding
alternative ways to benchmark the same thing) would be more effective.
Also, making it faster to run the benchmarks means that we can gather
more samples (i.e. do more "independent" runs on each commit), which
should reduce the noise more significantly than just running each
benchmark for longer.
Also note that going below 0.2s is not a clear win. Indeed, the speed
gain we obtain is not linear, since some benchmarks go past the
specified min time anyway, and the setup time still exists.
Assisted by Claude for the measurements and reasoning that led to
choosing 0.2s over other values.
Fixes #214055
Some SPIR-V™ instructions encode attribute-like operands as IDs of constant composite instructions. Deserialization currently fails when such an operand is defined by OpConstantCompositeReplicateEXT instead of OpConstantComposite. Materialize replicated composite constants as splat attributes when they are requested as constants. Check for replicated composites first when materializing SSA values so they remain spirv.EXT.ConstantCompositeReplicate operations.
There were a few tests for `lldb.value` in TestValueAPI.py, but they only checked conversion to `int` and `__bool__`. The class has more operators. Some of the operators were never tested, because they currently fail. This does the first step in that it adds tests.
`__nonzero__`, `__div__`, `__hex__`, and `__oct__` are from Python 2 and not used in Python 3, so remove them.
…lysis (#214639) sizeof(VFInfo) is 280 bytes, exceeding SmallVector's default 256-byte inline-storage limit, which trips a static_assert in debug builds. Explicitly specify an inline element count of 4, matching the existing convention used elsewhere for SmallVector<VFInfo, N> (e.g. Intel_SLPVectorizer.cpp, VectorUtils.h). Guilty commit: fb831c7 Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
) Currently (sub X, (vscale * C)) is combined to (add X, (vscale * -C)) only if (vscale * C) has a single use. If (vscale * -C) is a legal add immediate then we know the add will become a single instruction, so it's always profitable. In AArch64TargetLowering::isLegalAddImmediate we also need to check useScalarIncVL to correctly decide if the immediate is legal.
Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This is the initial straight rename commit. It will probably break the docs build, but it has to be a separate PR for blame preservation purposes.
…wn (#214352) Tracking issue: #201242 See the [migration guide] for more information. [migration guide]: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines This is a stacked PR based on #214351 , which will be a standalone commit that renames *.rst -> *.md before this PR lands for history preservation purposes. This PR is structured as two commits: 1. Mechanical, using a fork of rst2myst 2. Agentic cleanup This structure is used so we can determine why the markdown is the way it is: either it's rst2myst output, or an agent thought it was a defect, or it needed manual cleanup to build and pass validation. I paged through all the generated HTML looking for migration artifacts, and all of the differences I could find appear to be formatting error corrections. Please spot check my work and approve if it looks good.
…e dirs (#209312) This allows making __config_site modular. It also removes a workaround where the __config_site and __assertion_handler headers were previously excluded from the modulemap test.
It is generally not safe to rematerialize convergent instructions to different scheduling regions/blocks. This adds a check to the scheduler's `PreRARematStage` to prevent rematerialization of convergent instructions in all cases.
The checker `security.ArrayBound` had a special case for not reporting the `&array[size]` expressions where `size` is equal to the the element count of `array`. (Note that `array[size]` is reported as out-of-bounds access, but `&array[size]` does not actually access the past-the end location and it is an idiomatic way of expressing the past-the-end pointer.) The primary goal of this change is that it simplifies the contract of `bounds::checkBounds` which previously had a flag to act as if forming this past-the-end pointer was valid in-bounds access. With the new implementation, `checkBounds()` diagnoses the `&array[size]` expression as out-of-bounds access, then `ArrayBoundChecker.cpp` postprocesses this result and suppresses the report when it detects that it was an idiomatic `&array[size]` expression. This also removes an ugly but practically irrelevant corner case: the old code for recognizing an idiomatic past-the-end pointer expression also accepted it when the index (`size`) was constrained as "either negative, or the element count of the array" (becasue the "assume lower bound" step happens before checking the upper bound). (The new code only accepts `&array[size]` as an idiomatic past-the end pointer if `size` is constrained to be equal to the element count.)
…SensitiveOps (#214424) Fix an assertion crash (release: null-MBB walk) when a sub-pow2 sign-sensitive op has no preceding G_TRUNC to set the insert point
…d ByteCode evaluators (#213750) To clarify the purpose of floating-point status checks in AST and ByteCode evaluators during translation (as opposed to mandatory constant expression evaluation): - Rename checkFloatingPointResult to checkFloatingPointResultForConstantFolding in ExprConstant.cpp - Update its Doxygen documentation comment - CheckFloatResult in Interp.cpp is essentially the same as (Result NaN check + checkFloatingPointResultForConstantFolding). So we split the part that is equivalent to checkFloatingPointResultForConstantFolding in CheckFloatResult into a separate CheckFloatStatus function.
Remove test cases and naming highlighting the boundary non-unit dim requirement - this has been relaxed in the current implementation.
… memory operand (#212916) `getTgtMemIntrinsic` describes the access of the bit-reverse load intrinsics (`llvm.hexagon.L2.loadr*.pbr`) by attaching the underlying object of the base pointer to the machine memory operand, for alias analysis. Such a load post-increments its base pointer by the modifier, and accesses the address formed by reversing the low 16 bits of that pointer: memXX(Rx++Mu:brev) EA = Rx.h : bitrev(Rx.l) So a load in a chain of them accesses the base pointer of the chain, plus the bit-reverse of the sum of the modifiers of the loads before it. The offset was always zero, so every load of a chain claimed to access the first bytes of the object. Alias analysis concluded a store elsewhere in the object could not alias the loads, the scheduler sank it below them, and the loads read stale data. The object was described even when it could not be. Only the low 16 bits take part in the reversal, so the access stays inside the object only when those bits are zero, that is when the object is 64K aligned. Otherwise the reversed bits can name an address anywhere in the surrounding 64K region, possibly outside the object, and no offset computation can make that sound. Compute the offset, and otherwise say nothing. Pointer information is attached only when the underlying object is a pointer aligned to 64K, and every modifier in the chain is a constant whose running sum is non-negative and fits in 16 unsigned bits. --------- Co-authored-by: Sumanth Gundapaneni <sgundapa@quicinc.com> Co-authored-by: Yashas Andaluri <yandalur@qti.qualcomm.com>
The OpenCL C spec allows the implementation to choose the value of the `FP_ILOGBNAN` macro between `INT_MIN` and `INT_MAX`. This patch makes the value configurable by introducing a new macro `__OPENCL_FP_ILOGBNAN_MIN`. The default value is unchanged and is set to `INT_MAX`. If the new macro is defined, the value of `FP_ILOGBNAN` will be set to `INT_MIN`. This change makes the OpenCL C headers similar to the LLVM `libc`, that also has the `FP_ILOGBNAN` macro configurable.
#210952) Closes the stride-verification gap left open by #204611 and #205869. `vector.maskedload`/`maskedstore`/`expandload`/`compressstore` lower to LLVM masked intrinsics that read/write N *consecutive* elements from a single pointer (see [LangRef](https://llvm.org/docs/LangRef.htm)), but none of them verified the memref's minor-dim stride, so `strided<[2]>` verified successfully and silently miscompiled. This PR rejects statically-known non-unit and dynamic strides. **Stacked on #211004** --------- Signed-off-by: Federico Bruzzone <federico.bruzzone.i@gmail.com>
…ion (#205263) x86 has no vector integer divide instruction so a vector `udiv` by a variable divisor scalarizes into N scalar divides. Since there is no vector idiv to fall back on, lowering through vector float division is better. This is implemented as a new DAG combine (combineIntDivRem in X86ISelLowering.cpp) that runs before legalization and rewrites the vector divide before it scalarizes. Handles udiv, sdiv, urem and srem. - <=32-bit elements (i8/i16/i32): a single float divide (f32 for <=16-bit, f64 for 32-bit) recovers the exact quotient because the operands fit the mantissa (https://lemire.me/blog/2017/11/16/fast-exact-integer-divisions-using-floating-point-operations/). Enabled from SSE2. Part of #201319.
…0981) LLDB.h is a header that includes (nearly) every SB API header indirectly. This patch replaces the use of this header in some .cpp tests by instead directly including the needed headers. This is mainly to reduce compilation times of these files as they are recompiled on each test run.
Narrow the scope of test files by separating them by the patterns they exercise, for readability.
…214752) Would otherwise hide use-after-free because memory stays valid if it's in the pool.
…SUBREG_TO_REG for extension to 256/512-bit vectors (#212950) We often end up with duplicate "all zero" registers as they are represented by different psuedos for 128/256/512-bit types. Whilst they are nearly always free/cheap to rematerialize, its a waste of instructions and registers to needlessly do this. This patch only uses 128-bit SET0 calls and makes use of AVX's implicit zeroing of the upper elements (via SUBREG_TO_REG). AVX512F-only targets still use 512-bit VPXORDZrr instructions if they need to zero xmm16-xmm31, otherwise they fallback to VXORPSrr like regular AVX.
…4725) This relaxes one of the constraints on rematerialization candidates in the scheduler's `PreRARematStage`. The current implementation only allows rematerializing a register if it has a single user. This allows it when a register has multiple users in the same region. In such cases the register is rematerialized once just before the first user in program order. The cost model for assessing rematerialization opportunities stays unchanged since a register is only ever rematerialized to a single location.
Also fix alignment comparison in AMDGPU rtl.cpp.
Checks that directly reference MISRA/AUTOSAR are not accepted for legal/license reasons. Generic overlapping checks without such links remain fine. Fixes #160940
Make the BF16 form of G_FCONSTANT legal. Widen BF16 G_FADD, G_FMUL, G_FMA, and G_FCANONICALIZE to F32.
`select` on <2 x bfloat> has no operation action registered, so it defaults to Expand. The vector legalizer scalarizes it into two 16-bit selects, which are promoted to i16 and selected as a pair of V_CNDMASK_B16 plus shifts and a repack to reassemble the result on targets without true16.
…function in case of -ffp-model=strict" (#214751) the commit 7e1aba7 cause following problem: Commit 7e1aba7 moved setOperationAction(IS_FPCLASS, MVT::f32/f64, Custom) to an unconditional block, causing all PPC targets — including powerpc64-ibm-aix -m32 — to mark IS_FPCLASS as Custom. This exposed two crashes when compiling compiler-rt/builtins for 32-bit AIX (-m32 -mcpu=pwr7): Crash 1 — masks fcFinite/fcInf/fcInf|fcNan at -O2 (divdc3.c, muldc3.c) At -O2, IS_FPCLASS nodes carry the nofpexcept flag. For mask 504 (fcFinite, from __builtin_isfinite under -ffp-model=strict) and mask 519 (fcInf|fcNan, injected post-legalize when SimplifySetCC transforms SETUEQ(fabs(x), +inf) into a new IS_FPCLASS node), LowerIS_FPCLASS returned SDValue(). This caused ExpandNode to call expandIS_FPCLASS post-legalize, which fell to the integer-bitcast path computing IntVT = i64. Since i64 is not a legal type on PPC32, this crashed with: fatal error: error in backend: Cannot select: t9: i1 = is_fpclass nofpexcept t8, TargetConstant:i32<519> Crash 2 — masks fcNan/~fcNan at -O0 (divdc3.c) At -O0, IS_FPCLASS nodes lack nofpexcept, so expandIS_FPCLASS's float-comparison path is skipped entirely for all masks. For masks 504/516/519 this triggers the same integer-bitcast crash as above. For masks 3 (fcNan) and 1020 (~fcNan), LowerIS_FPCLASS reached the fcmpu/xscmpudp path added by 7e1aba7, but that path emitted getNOT(..., MVT::i1) — an XOR on MVT::i1. Since useCRBits=false on pwr7 and earlier targets, MVT::i1 is not a legal type, triggering:: Assertion failed: "Unexpected illegal type!" in LegalizeDAG.cpp This crash was hidden at -O2 because nofpexcept caused those nodes to be handled by expandIS_FPCLASS before reaching LowerIS_FPCLASS. This reverts commit 7e1aba7.
Fixing code style warnings in the CIRGenExprComplex file
…210992) Previously stack protection used hardcoded registers which could conflict with registers being used by user code. This fixes a bug where clang -fstack-clash-protection would cause local variables to be trashed by the stack probing loop. The implementation is following the pattern of the AArch64 and X86 backends. Utility function getLiveRegsForEntryMBB has been copied from AArch64FrameLowering.cpp and findScratchNonCalleeSaveRegister is loosely based on the AArch64 version. This fixes Github issue #198699
Fixed #209248 Implemented analogous to existing FMINNUM/FMAXNUM cases
Apparently, the new tests introduced by #212641 and #212861 use features not supported on ARM. Example: ``` FAIL: test_save_core_range_with_unreadable_tail_dwarf (TestProcessSaveCoreMinidumpPartialRead.ProcessSaveCoreMinidumpPartialReadTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File ".../lldbtest.py", line 2171, in test_method return attrvalue(self) File ".../TestProcessSaveCoreMinidumpPartialRead.py", line 78, in test_save_core_range_with_unreadable_tail self.assertSuccess(process.SaveCore(options)) File ".../lldbtest.py", line 3045, in assertSuccess self.fail(self._formatMessage(msg, "'{}' is not success".format(error))) AssertionError: 'architecture arm not supported.' is not success Config=arm-/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/bin/clang ```
Our premerge checks were testing the softfp build for armv8m. Adding also a hard float ABI check for this target to increase build check coverage. Assisted-by: Gemini
`cl` seems to have exceptions enabled by default and works fine, but `clang-cl` doesn't, so it errors about `try` being used even though exceptions are disabled. I found this trying to enable our Windows CI buildbot. Signed-off-by: Nick Sarnie <nick.sarnie@intel.com>
This adds the `CommonABIRuntime` as a base for all C++ ABIs and moves `LookupTypeByName` into it, so it can be reused.
…le (#210373) This PR originates from #205382. Heap sanitization helps us to proactively detect UAF and DF. According to the discussion in #205382, we separate this feature out from hardening concerns. Together in this patch: 1. We introduce `LIBC_HARDENING_MODE` similar to `libcxx`'s counterpart. 2. Introduce `_LIBC_ASSERT(COND, MSG)` as an always-on assertion macro and forward original `LIBC_ASSERT` to it under debug mode. Side note: I notice that LSB actually say that assert failure needs to **abort** the program. We need to fix that. `abort` allows reentrancy (recursive assertion failure) but current pure-header-library style makes cyclic dependency unavoidable. This should be cleaned up later. Opened as #211348. Assisted-by: Gemini powered automation tools (human-in-the-loop).
After moving to extended LLT, we've started seeing a pattern of `G_BITCAST(G_CONSTANT ...)` and `G_BITCAST(G_FCONSTANT ...)` being emitted due to float types now being distinct from integer types. This prevented certain optimization from detecting constants and led to worse results. This patch folds this pattern in CSEMIRBuilder.
Currently when iterating across the symbol table with the object library (in tools like nm/ar), some symbols that we wouldn't expect to be Global to the binder get flagged as SF_Global. With GOFF, we should exclude ESD entries who's type or binding scope make them unavailable for binder to use at Global scope. The implementation currently only filters the Section binding scopes when setting the Global flag, so this change adds filters for SD/ED type records and Module scope as well (which restricts the def to only the current module). We also add a test that checks ESD records for various types and binding strengths to see that we get the expected values.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )