[pull] main from llvm:main #743
Merged
Conversation
This file contains 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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Reduced/expanded from issue #57683.
As shown in the examples in issue #57683, we allow matching vectors with poison (undef) in this transform (and possibly more), but we can't then use the partially defined value as a replacement value in other expressions blindly. This seems to be avoided in simpler examples of reassociation, and other passes should be able to clean up the redundant op seen in these tests.
The CMake variable LLDB_HAS_LIBCXX is passed to
`llvm_canonicalize_cmake_booleans`, which transforms TRUE/FALSE into
'1'/'0'. It also transforms undefined variables to '0'.
In particular, this means that the configuration script for LLDB API's
test always has _some_ value for the `has_libcxx` configuration:
```
config.has_libcxx = '@LLDB_HAS_LIBCXX@'
```
When deciding whether a libcxx exist, the testing scripts would only
check for the existence of `has_libcxx`, but not for its value. In other
words, because `if ('0')` is true in python we always think there is a
libcxx.
This was caught once D132940 was merged and most tests started to use
libcxx by default if `has_libcxx` is true. Prior to that, no failures
were seen because only tests are marked with
`@add_test_categories(["libc++"])` would require a libcxx, and these
would be filtered out on builds without the libcxx target. Furthermore,
the MacOS bots always build libcxx.
We fix this by making `has_libcxx` a boolean (instead of a string) and
by checking its value in the test configuration.
Differential Revision: https://reviews.llvm.org/D133639
ALU seems a little vague. FAdd felt more precise even though it also include FSUB instructions. Reviewed By: monkchiang Differential Revision: https://reviews.llvm.org/D133632
…lution It's not possible to use a template with no definition from another translation unit. Fixes the shared library build.
Make the default module cache path invalid when running lit tests so that tests are forced to provide a cache path. This avoids accidentally escaping to the system default location, and would have caught the failure recently found in ClangScanDeps/multiple-commands.c. Differential Revision: https://reviews.llvm.org/D133622
…ad slices
This patch adds additional vector types to be considered when doing
promotion in SROA, based on the types of the store and load slices. This
provides more promotion opportunities, by potentially using an optimal
"intermediate" vector type.
For example, the following code would currently not be promoted to a
vector, since `__m128i` is a `<2 x i64>` vector.
```
__m128i packfoo0(int a, int b, int c, int d) {
int r[4] = {a, b, c, d};
__m128i rm;
std::memcpy(&rm, r, sizeof(rm));
return rm;
}
```
```
packfoo0(int, int, int, int):
mov dword ptr [rsp - 24], edi
mov dword ptr [rsp - 20], esi
mov dword ptr [rsp - 16], edx
mov dword ptr [rsp - 12], ecx
movaps xmm0, xmmword ptr [rsp - 24]
ret
```
By also considering the types of the elements, we could find that the
`<4 x i32>` type would be valid for promotion, hence removing the memory
accesses for this function. In other words, we can explore other new
vector types, with the same size but different element types based on
the load and store instructions from the Slices, which can provide us
more promotion opportunities.
Additionally, the step for removing duplicate elements from the
`CandidateTys` vector was not using an equality comparator, which has
been fixed.
Differential Revision: https://reviews.llvm.org/D132096
A next step towards supporting the new dimension level types and properties. This changes properly records the properties in the Merger, so that subsequent computations (lattice optimizations) and code generation (during sparsification) can do the right thing. #51658 Reviewed By: Peiming Differential Revision: https://reviews.llvm.org/D133620
TargetLibraryInfo isn't optional, so we have to provide it even with the lageacy stuff. Ideally we wouldn't need it anymore but there are still users out there that are stuck on the legacy PM. Differential Revision: https://reviews.llvm.org/D133685
…constants. For remainder: If (1 << (Bitwidth / 2)) % Divisor == 1, we can add the high and low halves together and use a (Bitwidth / 2) urem. If (BitWidth /2) is a legal integer type, this urem will be expand by DAGCombiner using multiply by magic constant. We do have to take into account that adding high and low together can produce a carry, making it a (BitWidth / 2)+1 bit number. So we need to also add back in the carry from the first addition. For division: We can use the above trick to compute the remainder, subtract that remainder from the dividend, then multiply by the multiplicative inverse of the Divisor modulo (1 << BitWidth). This is based on the section "Remainder by Summing Digits" in Hacker's delight. The remainder trick is similar to a trick you may have learned for determining if a decimal number is divisible by 3. You can add all the digits together and see if the sum is divisible by 3. If you're not sure if the sum is divisible by 3, you can add its digits together. This can be repeated until you have a single decimal digit. If that digit is 3, 6, or 9, then the original number is divisible by 3. This works because 10 % 3 == 1. gcc already does this same trick. There are additional tricks gcc does urem as well as srem, udiv, and sdiv that I plan to add in future patches. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D130862
* Include SetCallback in SBBreakpointLocation, similar as in SBBreakpoint. * Add test_breakpoint_location_callback test as part of TestMultithreaded. Reviewed By: werat, JDevlieghere Differential Revision: https://reviews.llvm.org/D133689 Co-authored-by: Andy Yankovsky <weratt@gmail.com>
…when debug info is valid." This reverts commit 9af089f. This broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/23528
Sort additional module maps when serializing pcm files. This ensures the `MODULE_MAP_FILE` record is deterministic across repeated builds. Reviewed By: benlangmuir Differential Revision: https://reviews.llvm.org/D133611
If we don't add local variables with no location info, when trying to print it, lldb won't find it in the its parent DeclContext, which makes lldb to spend more time to search all the way up in DeclContext hierarchy until found same name variable or failed. Dwarf plugin also add local vars even if they don't have location info. Differential Revision: https://reviews.llvm.org/D133626
This commit improves upon cc0b5eb, which added support for specifying which libcxx to use when testing LLDB. That patch honored requests by tests that had `USE_LIBCPP=1` defined in their makefiles. Now, we also use a non-default libcxx if all conditions below are true: 1. The test is not explicitly requesting the use of libstdcpp (USE_LIBSTDCPP=1). 2. The test is not explicitly requesting the use of the system's library (USE_SYSTEM_STDLIB=1). 3. A path to libcxx was either provided by the user through CMake flags or libcxx was built together with LLDB. Condition (2) is new and introduced in this patch in order to support tests that are either: * Cross-platform (such as API/macosx/macCatalyst and API/tools/lldb-server). The just-built libcxx is usually not built for platforms other than the host's. * Cross-language (such as API/lang/objc/exceptions). In this case, the Objective C runtime throws an exceptions that always goes through the system's libcxx, instead of the just built libcxx. Fixing this would require either changing the install-name of the just built libcxx in Mac systems, or tuning the DYLD_LIBRARY_PATH variable at runtime. Some other tests exposes limitations of LLDB when running with a debug standard library. TestDbgInfoContentForwardLists had an assertion removed, as it was checking for buggy LLDB behavior (which now crashes). TestFixIts had a variable renamed, as the old name clashes with a standard library name when debug info is present. This is a known issue: #34391. For `TestSBModule`, the way the "main" module is found was changed to look for the "a.out" module, instead of relying on the index being 0. In some systems, the index 0 is dyld when a custom standard library is used. Differential Revision: https://reviews.llvm.org/D132940
1. Fixed rST hyperlink syntax 2. Renamed LD64 -> ld64 3. Moved up the `-no_deduplicate` section so it is right under the section talking about how our default dedup behavior differs; IMO it makes more sense to read them in that order 4. De-bullet-listed some other sections so we have less whitespace in the rendered page 5. Since the Mach-O LLD Port page has only one sub-page, don't render an entire toctree with just one item. Use a "See also" box instead. 6. Wrap lines at 80 chars. Reviewed By: #lld-macho, thevinster Differential Revision: https://reviews.llvm.org/D133717
* Change `Symbol::flags` to a `std::atomic<uint16_t>` * Add `llvm::parallel::threadIndex` as a thread-local non-negative integer * Add `relocsVec` to part.relaDyn and part.relrDyn so that relative relocations can be added without a mutex * Arbitrarily change -z nocombreloc to move relative relocations to the end. Disable parallelism for deterministic output. MIPS and PPC64 use global states for relocation scanning. Keep serial scanning. Speed-up with mimalloc and --threads=8 on an Intel Skylake machine: * clang (Release): 1.27x as fast * clang (Debug): 1.06x as fast * chrome (default): 1.05x as fast * scylladb (default): 1.04x as fast Speed-up with glibc malloc and --threads=16 on a ThunderX2 (AArch64): * clang (Release): 1.31x as fast * scylladb (default): 1.06x as fast Reviewed By: andrewng Differential Revision: https://reviews.llvm.org/D133003
… lit tests" This reverts commit d96f526. Some systems do not support `env -u`.
…and RegisterLiveOut MachineOperand::getRegMask() returns a pointer to register mask. We should hash the raw content of register mask instead of its pointer. Reviewed By: kyulee Differential Revision: https://reviews.llvm.org/D133637
I'm planning to deprecate and eventually remove llvm::empty. I thought about replacing llvm::empty(x) with std::empty(x), but it turns out that all uses can be converted to x.empty(). That is, no use requires the ability of std::empty to accept C arrays and std::initializer_list. Differential Revision: https://reviews.llvm.org/D133677
…ug info is valid. Summary: Many times when debugging variables might not be available even though a user can successfully set breakpoints and stops somewhere. Letting the user know will help users fix these kinds of issues and have a better debugging experience. Examples of this include: - enabling -gline-tables-only and being able to set file and line breakpoints and yet see no variables - unable to open object file for DWARF in .o file debugging for darwin targets due to modification time mismatch or not being able to locate the N_OSO file. This patch adds an new API to SBValueList: lldb::SBError lldb::SBValueList::GetError(); object so that if you request a stack frame's variables using SBValueList SBFrame::GetVariables(...), you can get an error the describes why the variables were not available. This patch adds the ability to get an error back when requesting variables from a lldb_private::StackFrame when calling GetVariableList. It also now shows an error in response to "frame variable" if we have debug info and are unable to get varialbes due to an error as mentioned above: (lldb) frame variable error: "a.o" object from the "/tmp/libfoo.a" archive: either the .o file doesn't exist in the archive or the modification time (0x63111541) of the .o file doesn't match Reviewers: labath JDevlieghere aadsm yinghuitan jdoerfert sscalpone Subscribers: Differential Revision: https://reviews.llvm.org/D133164
Rationale: For every dynamic memref (memref<?xtype>), the stored size really indicates the capacity and the entry in the memSizes indicates the actual size. This allows us to use memref's as "vectors". Reviewed By: Peiming Differential Revision: https://reviews.llvm.org/D133724
__declspec(safebuffers) is equivalent to __attribute__((no_stack_protector)). This information is recorded in CodeView. While we are here, add support for strict_gs_check.
Somehow DeadMachineInstructionElim is about 3x slower when using it. Hopefully this reverses the compile time regression reported for b504152.
This adds llvm-remarkutil. This is intended to be a general tool for doing stuff with/to remark files. This patch gives it the following powers: * `bitstream2yaml` - To convert bitstream remarks to YAML * `yaml2bitstream` - To convert YAML remarks to bitstream remarks These are both implemented as subcommands, like `llvm-remarkutil bitstream2yaml <input_file> -o -` I ran into an issue where I had some bitstream remarks coming from CI, and I wanted to be able to do stuff with them (e.g. visualize them). But then I noticed we didn't have any tooling for doing that, so I decided to write this thing. Being able to output YAML as a start seemed like a good idea, since it would allow people to reuse any tooling they may have written based around YAML remarks. Hopefully it can grow into a more featureful remark utility. :) Currently there are is an outstanding performance issue (see the TODO) with the bitstream2yaml case. I decided that I'd keep the tool small to start with and have the yaml2bitstream and bitstream2yaml cases be symmetric. Also I moved the remarks documentation to its own header because it seems a little out of place with "basic commands" and "developer tools"; it's really kind of its own thing. Differential Revision: https://reviews.llvm.org/D133646
Doc builder caught this:
```
File ".../llvm/src/llvm/docs/conf.py", line 271, in process_rst
name,description = title.split(' - ', 1)
ValueError: not enough values to unpack (expected 2, got 1)
```
…dden/protected applied to dllimport Hidden visibility is incompatible with dllexport. Hidden and protected visibilities are incompatible with dllimport. (PlayStation uses dllexport protected.) When an explicit visibility attribute applies on a dllexport/dllimport declaration, report a Frontend error (Sema does not compute visibility). Reviewed By: mstorsjo Differential Revision: https://reviews.llvm.org/D133266
…tTilingInterface.cpp (NFC)
…rTypeFormatGen.cpp (NFC)
… types. The mutation the action generates tries to change the input type into the element type of larger vector type. This doesn't work if the larger element type is a vector of pointers since it creates an illegal mutation between scalar and pointer types. Differential Revision: https://reviews.llvm.org/D133671
The bit masking lowering only works for vectors of scalars, so for pointer element types we need to add some casting. Differential Revision: https://reviews.llvm.org/D133672
…unctionality This patch refactors SlotIndex::getInstrDistance to SlotIndex::getApproxInstrDistance to better describe the actual functionality of this function. This patch also adds in some additional comments better documenting the assumptions that this function makes to increase clarity. Based on discussion on the LLVM Discourse: https://discourse.llvm.org/t/odd-behavior-in-slotindex-getinstrdistance/64934/5 Reviewed By: mtrofin, foad Differential Revision: https://reviews.llvm.org/D133386
Unfortunately these options are still not upstream.
The ORC runtime isn't used by clang -- the prefix was just cargo-culted with the rest of the XRay config when the ORC runtime was introduced. We now want to make parts of it available for clients to link directly, so this seems like a good time to fix the name.
Debugging some DWARF5 binaries was causing errors to appear when DWARFExpression::Evaluate was called:
error: GetDIE for DIE 0x31 is outside of its CU 0x123450
The issue is in the DWARF expression evaluator. Fixed with this.
Differential Revision: https://reviews.llvm.org/D133623
Some compilers (like all the ones I've tried) seem to NVRO the Expected<std::vector<unique_ptr>> but other ones (like some of the bots) seem to not want to. Change the return type to Error and pass in the vector as an output parameter to try and fix things.
The ORC runtime include directory was renamed from 'orc' to 'orc_rt' in a85e4aa. Update includes to match.
Fold cases where a tosa.reverse is a splat or reversing a dim of length-1. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D133144
…initionsGen.cpp (NFC)
llvm-lipo crashes when trying to use inputs that contain bitcode asm instructions. This happens when trying to create universal binaries for LLVM with LTO. https://reviews.llvm.org/D118575 is a similar change that ran into this same issue, and I'm mirroring the same change by registering the targets to fix this issue. Reviewed By: alexander-shaposhnikov, keith Differential Revision: https://reviews.llvm.org/D133729
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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]
Can you help keep this open source service alive? 💖 Please sponsor : )