Merged
Conversation
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
…168447) 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).
…m#168292) (llvm#168786) This reverts commit 6d5f87f. Previously this failed due to treating the unknown MachineMemOperand value as known uniform.
…lvm#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 llvm#146602, while `supports_hw_breakpoints()` was changed in llvm#146609, which was landed earlier despite having a bigger number.
…econstructing DIE names (llvm#168734) Depends on: * llvm#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`)
llvm#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.
…lvm#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.
…pInterface.cpp (NFC)
…vm#162952) Pyright is an MIT-licensed static type checker and can be found at https://github.com/microsoft/pyright there are also various integrations to use it as an LSP server in various editors which is the main way I use it. It's useful on our python scripts to detect issues such as where functions are called with unexpected types or it's possible to access obj.attr on an object that doesn't have that attribute. It can be used without any configuration this config setting causes it to also report issues with type hints that do not meet our python 3.8 minimum such as this one from dap_server.py: ``` init_commands: list[str], ``` subscripting the builtin type like that requires python 3.9 while the 3.8 equivalent is: ``` from typing import List ... init_commands: List[str], ``` In practice these scripts still work on 3.8 because type hints aren't normally evaluated during normal execution but since we have a minimum, we should fully comply with it. Note: The error pyright reports for this particular issue isn't great: ``` error: Subscript for class "list" will generate runtime exception; enclose type expression in quotes ``` This is technically correct as it is possible to evaluate type hints at runtime but I believe anything that would do so would also evaluate the string form as well and still hit the runtime exception. A better suggestion in this case would have been the 3.8 compatible `List[str]`. However, it is better than silently passing code that doesn't confirm to the minimum.
…lvm#168795) This test explicitly sets the environment for a spawned process. Without DYLD_LIBRARY_PATH, the spawned process may use a ASAN runtime other than the one that was used by the parent process That other runtime library may not work at all, or may not be in the default search path. Either case can cause the spawned process to die before it makes it to main, thus failing the test. The compiler-rt lit config sets the library path variable [here](https://github.com/llvm/llvm-project/blob/main/compiler-rt/test/lit.common.cfg.py#L84) (i.e. to ensure that just-built runtimes are used for tests, in the case of a standalone compiler-rt build), and that is currently used by the parent process but not the spawned ones. My change only forwards the variable for Darwin (DYLD_LIBRARY_PATH), but we **_ought_** to also forward the variable for other platforms. However, it's not clear that there's any good way to plumb this into the test, since some platforms actually have multiple library path variables which would need to be forwarded (see: SunOS [here](https://github.com/llvm/llvm-project/blob/main/compiler-rt/test/lit.common.cfg.py#L102)). I considered adding a substitution variable for the library path variable, but that doesn't really work if there's multiple such variables.
This reverts commit b725bdb. This is still causing Darwin failures. There are six tests that are still failing: AddressSanitizer-x86_64-darwin.TestCases/Posix.deep_call_stack.cpp AddressSanitizer-x86_64-darwin.TestCases.scariness_score_test.cpp AddressSanitizer-x86_64h-darwin.TestCases/Posix.deep_call_stack.cpp ORC-x86_64-darwin.TestCases/Darwin/x86-64.objc-imageinfo.S UBSan-Minimal-x86_64-darwin.TestCases.test-darwin-interface.c UBSan-Minimal-x86_64h-darwin.TestCases.test-darwin-interface.c There are a couple failure modes: 1. deep_call_stack.cpp and scariness_score_test.cpp are failing due to ulimit issues that we have observed previously. 2. objc-imageinfo.S is failing in the x86 variant because I only updated the AArch64 variant. 3. test-darwin-interface.c is using subshells, so obviously fails with the internal shell. Also looks like this one did not run on my system due to it requiring x86_64 Darwin.
Add extra tests for over-eager tail-folding for tiny trip-count loops. Reduced from llvm#167858.
This has been replaced by the MODULE.bazel file. Users can still use their own WORKSPACE files, but they didn't inherit this file anyways. Users should migrate to bzlmod as with bazel 9.x that is required.
Need to check if the non-schedulable phi parent node has unique operands, if the incoming node has copyables, and the node is commutative. Otherwise, there might be issues with the correct calculation of the dependencies. Fixes llvm#168589
…on iOS/Android (llvm#168821) The tests added by llvm#163468 appear to be broken due to lack of libcxx support (?). Marking unsupported everywhere for now since it passes on some platforms and fails on others, and I don't know the full list. Android fail: https://lab.llvm.org/buildbot/#/builders/186/builds/14106
…llvm#168289) Remove `VPWidenPointerInductionRecipe::IsScalarAfterVectorization` and replace it with `onlyScalarValuesUsed`. This removes the need to carry state from the legacy cost model through VPlan, and the VPlan-based analysis gives more accurate results, avoiding a number of extracts. PR: llvm#168289
Removes unused headers or replaces them with headers that directly provide the symbol instead. For example, `Serialize.h` included `AST.h`, but it was actually `Serialize.cpp` that needed concept expressions, so now it includes just `ExprConcepts.h`.
This is required for correctly loading the protobuf rules. It's possible we could drop the version here to a lower version, as long as that version supports the versions of bazel we support. I picked this because it is the current version being used by bazel 8.0.0 (which is defined in the .bazelversion). Users can override this in their project anyways if they need an older one
Collaborator
Author
Collaborator
|
!PSDB |
Collaborator
Author
ronlieb
approved these changes
Nov 20, 2025
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.