forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 2
[pull] main from llvm:main #5651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
pull
wants to merge
2,727
commits into
Ericsson:main
Choose a base branch
from
llvm:main
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
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
…168834) MachineBasicBlock::liveout_begin() calls this constructor with MCRegisters so this removes an implicit cast.
The dialect implementation mostly copies the one of `cf.switch`, but aligns naming to the SPIR-V spec.
This handles the AIX form of the thinLTO cache dir option, which get's turned on when thinLTO is enabled.
This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. I had to split `VSHUF4I` into two variants (`VSHUF4I` and `VSHUF4I_D`) since `loongarch_vshuf4i` and `loongarch_vshuf4i_d` have different number of operands, and this prevented the node from being imported. There is just one node that currently fails validation, see `LoongArchSelectionDAGInfo::verifyTargetNode()`. Part of #119709. Pull Request: #168129
Commit c9f5734 removed the file TargetLibraryInfo.def but did not remove it from the module map.
LoopPeel sometimes proves that, when reached, the original loop always executes at least two iterations. LoopPeel then unconditionally executes both the remaining loop's initial iteration and the peeled final iteration. But that increases the latter's frequency above its frequency in the original loop. To maintain the total frequency, this patch compensates by decreasing the remaininng loop's latch probability. This is another step in issue #135812 and was discussed at <#166858 (comment)>.
#162822 added another validation step to check if entries in a partial reduction chain have the same scale factor. But the validation was still dependent on the order of entries in PartialReductionChains, and would fail to reject some cases (e.g. if the first first link matched the scale of the second link, but the second link is invalidated later). To fix that, group chains by their starting phi nodes, then perform the validation for each chain, and if it fails, invalidate the whole chain for the phi. Fixes #167243. Fixes #167867. PR: #168036
Avoids regression which caused the revert 6d5f87f. This is a hack on a hack. We currently have isUniformMMO, which improperly treats unknown source value as known uniform. This is hack from before we had divergence information in the DAG, and should be removed. This is the minimum change to avoid the regression; removing the aggressive handling of the unknown case (or dropping isUniformMMO entirely) are more involved fixes.
Upstream ExtVectorElementExpr with rvalue base
We can't do anything meaningful to such functions: they aren't optimizable, and even if inlined, they would bring no code open to optimization.
To make life easier for future contributors. Note that formatting changes are due to git clang-format on the touched whitespace-error lines.
test/Lower/select-case-statement.f90 was still using the old lowering. Modified the test with FIR generated using the new lowering. Changed the test to use flang_fc1 instead of bbc and added testing for -O0 and -O1, since character comparison lowering is done differently at -O0 (uses runtime function) and -O1 (inlines some cases). Use different FileCheck prefixes for different optimization levels (CHECK-O0 for -O0, CHECK-O1 for -O1, CHECK for both).
…165416) This PR introduces new debug macros that allow a more fined control of which debug message to output and introduce C++ stream style for debug messages. Changing existing messages (except a few that I changed for testing) will come in subsequent PRs. I also think that we should make debug enabling OpenMP agnostic but, for now, I prioritized maintaing the current libomptarget behavior for now, and we might need more changes further down the line as we we decouple libomptarget.
If `HardwareBreakpointTestBase.supports_hw_breakpoints()` returns False, `SimpleHWBreakpointTest.does_not_support_hw_breakpoints()` returns None, so the test runs and fails. However, it should be skipped instead. The test was added in #146602, while `supports_hw_breakpoints()` was changed in #146609, which was landed earlier despite having a bigger number.
…econstructing DIE names (#168734) Depends on: * #168725 When compiling with `-glldb`, we repoint the `DW_AT_type` of a DIE to be a typedef that refers to the `preferred_name`. I.e.,: ``` template <typename T> structure t7; using t7i = t7<int>; template <typename T> struct __attribute__((__preferred_name__(t7i))) t7 {}; template <typename... Ts> void f1() int main() { f1<t7i>(); } ``` would produce following (minified) DWARF: ``` DW_TAG_subprogram DW_AT_name ("_STN|f1|<t7<int> >") DW_TAG_template_type_parameter DW_AT_type (0x0000299c "t7i") ... DW_TAG_typedef DW_AT_type (0x000029a7 "t7<int>") DW_AT_name ("t7i") ``` Note how the `DW_AT_type` of the template parameter is a typedef itself (instead of the canonical type). The `DWARFTypePrinter` would take the `DW_AT_name` of this typedef when reconstructing the name of `f1`, so we would end up with a verifier failure: ``` error: Simplified template DW_AT_name could not be reconstituted: original: f1<t7<int> > reconstituted: f1<t7i> ``` Fixing this allows us to un-XFAIL the `simplified-template-names.cpp` test in `cross-project-tests`. Unfortunately this is only tested on Darwin, where LLDB tuning is the default. AFAIK, there is no other case where the template parameter type wouldn't be canonical.
Currently the tests for LLVM targets `AArch64` and `ARM` were in the same directory. But if you only configured LLVM for one target (e.g., just `AArch64`, which is how I ran into this), then all tests under the ARM directory are marked `UNSUPPORTED`. This patch moves all the tests that are capable of running on `AArch64`-only targets into a dedicated `AArch64` directory. The tests that expected a plain `ARM` target were kept in the `ARM` directory. Drive-by: * Rename the `dummy-debug-map-amr64.map` to `dummy-debug-map-arm64.map` (note the typo in `amr64`)
#168619) I've been working on some scripts that evaluate the parent and child frame. It's been very annoying that the parent frame has a property but not the child. So I've added this to the extensions, I would've preferred to return None, but because the existing impl returns an invalid SBFrame, so I'm conforming to that API. ``` (lldb) script Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> lldb.frame frame #0: 0x0000555555555200 fib.out`main >>> lldb.frame.parent frame #1: 0x00007ffff782a610 libc.so.6`__libc_start_call_main + 128 >>> lldb.frame.parent.child frame #0: 0x0000555555555200 fib.out`main ```
When downloading bazelisk/buildifier, we use curl, which still returns exit code zero on HTTP 4xx errors unless we pass --fail. This patch adds --fail flags so that error messages are more clear.
…168918) We already know we're looking at BITREVERSE, we can match on the source operand.
There are several places where we use `llvm::OwningArrayRef`. The interface to this requires us to first construct temporary storage, then allocate space and set the allocated memory to 0, then copy the values we actually want into that memory, then move the array into place. Instead we can just do it all inline in a single pass by using `std::vector`. In one case we actually allocate a completely separate container and then allocate + copy the data over because `llvm::OwningArrayRef` does not (and can't) support `push_back`. Note that `llvm::SmallVector` is not a suitable replacement here because we rely on reference stability on move construction: when the outer container reallocates, we need the the contents of the inner containers to be fixed in memory, and `llvm::SmallVector` does not give us that guarantee.
Fixes #118187 Fixes #156579 An instantiated `LambdaExpr` can currently be marked as `LDK_NeverDependent` if it's nested within a generic lambda. If that `LambdaExpr` in fact depends on template parameters introduced by the enclosing generic lambda, then its dependence will be misreported as "never dependent" and spurious diagnostics can result. The fix here proposed is a bit ugly, but the condition that it's being bolted onto already seems like a bit of a hack, so this seems no worse for wear. Note that #89702 surfaced this change because it caused the inner lambda expression to (correctly) be considered in a constant-evaluated context. The affected check for whether to mark the inner lambda as `LDK_NeverDependent` therefore started to apply, whereas it didn't before. **Tested**: `check-clang` and `check-cxx`.
…#169182) I think we need to keep the SelectionDAG code for volatile load/store so we should support 4 byte alignment when possible.
This was missed in 0ef522f
BugSuppression works by traversing the lexical decl context of the decl-with-issue to record what source ranges should be suppressed by some attribute. Note that the decl-with-issue will be changed to the lexical decl context of the original decl-with-issue, to make suppression attributes work that were attached to the CXXRecordDecl containing the CXXMethodDecl (bug report's DeclWithIssue). It happens so that it uses a DynamicRecursiveASTVisitor, which has a couple of traversal options. Namely: - ShouldVisitTemplateInstantiations - ShouldWalkTypesOfTypeLocs - ShouldVisitImplicitCode - ShouldVisitLambdaBody By default, these have the correct values, except for ShouldVisitTemplateInstantiations. We should traverse template instantiations because that might be where the bug is reported - thus, where we might have a [[clang::suppress]] that we should honor. In this patch I'll explicitly set these traversal options to avoid further confusion. rdar://164646398
#168885) Add two more AST nodes, one for a misplaced end-directive, and one for an invalid string following the OpenMP sentinel (e.g. "!$OMP XYZ"). Emit error messages when either node is encountered in semantic analysis.
Fold any-of (fcmp uno %A, %A), (fcmp uno %B, %B), ... -> any-of (fcmp uno %A, %B), ... This pattern is generated to check if any vector lane is NaN, and combining multiple compares is beneficial on architectures that have dedicated instructions. Alive2 Proof: https://alive2.llvm.org/ce/z/vA_aoM Combine suggested as part of #161735 PR: #166823
…tures/Attributes blocks. NFC. (#169223)
Make it easier to use these containers as drop-in replacements for std::map.
… and flangFrontend (#165277) This removes the dependency on clangDriver from clangFrontend and flangFrontend. This refactoring is part of a broader effort to support driver-managed builds for compilations using C++ named modules and/or Clang modules. It is required for linking the dependency scanning tooling against the driver without introducing cyclic dependencies, which would otherwise cause build failures when dynamic linking is enabled. In particular, clangFrontend must no longer depend on clangDriver for this to be possible. This change was discussed in the following RFC: https://discourse.llvm.org/t/rfc-new-clangoptions-library-remove-dependency-on-clangdriver-from-clangfrontend-and-flangfrontend/88773
This PR adds `__builtin_operator_new` and `__builtin_operator_delete`. The implementation is taken from clang code gen.
The CMake [`set()`](https://cmake.org/cmake/help/latest/command/set.html) command does not accept a conditional expression as a value. As a result, AFFECTED_BY_SWIG_BUG was being set to a string representation of the condition rather than a boolean value, causing it to always evaluate as truthy in subsequent if-checks.
This test does not actually need to use the clang driver. Using the driver means that the environment plays much more into the tests results. We ran into a situation where the driver decided not to pass -fopenmp to the cc1 invocation, causing the test to fail. This also makes the test more consistent with the other OpenMP tests and should make it slightly faster (no subprocess invocation).
Co-authored-by: Aiden Grossman <[email protected]>
Fix VPlan SLP check incorrectly bailing out for non-VPInstructions. Starting from the beginning of the block will include canonical IVs, which in turn are not VPInstructions. If we hit a non-VPInstruction, we should conservatively treat is as potentially unvectorizable. To keep the tests working as expected, refine mayRead/WriteFromMemory for Load and GEP VPInstructions.
#167060)" (#169238) This reverts commit a52e1af. That commit reverted a change (making isExpandedFromMacro take a std::string) that was explicitly added to avoid lifetime issues. We ran into issues with some internal matchers due to this, and it probably is not an uncommon downstream use case. This patch restroes the original functionality and adds a test to ensure that the functionality is preserved. https://reviews.llvm.org/D90303 contains more discussion.
…64768) Background: X86 APX feature adds 16 registers within the same 64-bit mode. PR #164638 is trying to extend such registers for FASTCC. However, a blocker issue is calling convention cannot be changeable with or without a feature. The solution is to disable FASTCC if APX is not ready. This is an NFC change to the final code generation, becasue X86 doesn't define an alternative ABI for FASTCC in 64-bit mode. We can solve the potential compatibility issue of #164638 with this patch.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 : )