[pull] main from llvm:main #5548
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}
Closes [#124631](#124631). ref: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/endian.h.html This patch adds the implementation of `endian.h`, which includes the header itself and three related macros. These macros in the header rely on the compiler preprocessor, similar to how https://github.com/llvm/llvm-project/blob/main/libc/src/__support/endian_internal.h does. Hopefully this will meet the requirements for compiling llvm with llvm-libc.
…ape]] on a member function no longer works. (#126016)
…#125143) …uffer ValueObjectDynamicValue::UpdateValue() assumes that the dynamic type found by GetDynamicTypeAndAddress() would return an address in the inferior. This commit makes it so it can deal with being passed a host address instead. This is needed downstream by the Swift fork. rdar://143357274
) In Sep 2016 and newer Darwin releases, debugserver uses libdyld SPI to gather information about the binaries loaded in a process. Before Sep 2016, lldb would inspect the dyld internal data structures directly itself to find this information. DynamicLoaderDarwin::UseDYLDSPI currently defaults to the old inspect-dyld-internal-structures method for binaries (DynamicLoaderMacOSXDYLD). If it detects that the Process' host OS version is new enough, it enables the newer libdyld SPI methods in debugserver (DynamicLoaderMacOS). This patch changes the default to use the new libdyld SPI interfaces. If the Process has a HostOS and it is one of the four specific OSes that existed in 2015 (Mac OS X, iOS, tvOS, watchOS) with an old version number, then we will enable the old DynamicLoader plugin. If this debug session is a corefile, we will always use the old DynamicLoader plugin -- the libdyld SPI cannot run against a corefile, lldb must read metadata or the dyld internal data structures in the corefile to find the loaded binaries.
#126020) On some OS distros such as LoongArch Fedora 38 mate-5 [1], there are no macro definitions NT_LOONGARCH_HW_BREAK and NT_LOONGARCH_HW_WATCH in the system header, then there exist some errors when building LLDB on LoongArch. (1) Description of Problem: ``` llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp:529:16: error: 'NT_LOONGARCH_HW_WATCH' was not declared in this scope; did you mean 'NT_LOONGARCH_LBT'? 529 | int regset = NT_LOONGARCH_HW_WATCH; | ^~~~~~~~~~~~~~~~~~~~~ | NT_LOONGARCH_LBT llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp:543:12: error: 'NT_LOONGARCH_HW_BREAK' was not declared in this scope; did you mean 'NT_LOONGARCH_CSR'? 543 | regset = NT_LOONGARCH_HW_BREAK; | ^~~~~~~~~~~~~~~~~~~~~ | NT_LOONGARCH_CSR ``` (2) Steps to Reproduce: ``` git clone https://github.com/llvm/llvm-project.git mkdir -p llvm-project/llvm/build && cd llvm-project/llvm/build cmake .. -G "Ninja" \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_BUILD_RUNTIME=OFF \ -DLLVM_ENABLE_PROJECTS="clang;lldb" \ -DCMAKE_INSTALL_PREFIX=/usr/local/llvm \ -DLLVM_TARGETS_TO_BUILD="LoongArch" \ -DLLVM_HOST_TRIPLE=loongarch64-redhat-linux ninja ``` (3) Additional Info: Maybe there are no problems on the OS distros with newer glibc devel library, so this issue is related with OS distros. (4) Root Cause Analysis: This is because the related Linux kernel commit [2] was merged in 2023-02-25 and the glibc devel library has some delay with kernel, the glibc version of specified OS distros is not updated in time. (5) Final Solution: One way is to ask the maintainer of OS distros to update glibc devel library, but it is better to not depend on the glibc version. In order to avoid the build errors, just define NT_LOONGARCH_HW_BREAK and NT_LOONGARCH_HW_WATCH in LLDB if there are no these definitions in the system header. By the way, in order to fit within 80 columns, use C++-style comments for the new added NT_LOONGARCH_HW_BREAK and NT_LOONGARCH_HW_WATCH. While at it, for consistency, just modify the current NT_LOONGARCH_LSX and NT_LOONGARCH_LASX to C++-style comments too. [1] https://mirrors.wsyu.edu.cn/fedora/linux/development/rawhide/Everything/loongarch64/iso/livecd-fedora-mate-5.loongarch64.iso [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a69f7a161a7 Signed-off-by: Tiezhu Yang <[email protected]>
…was missing Summary: This code is intended to block transformations if the call isn't present, however the way it's coded it silently lets it pass if the definition doesn't exist at all. This previously was always valid since we included the runtime as one giant blob so everything was always there, but now that we want to move towards separate ones, it's not quite correct.
This is a tiny change that can save up to 16 bytes of stack allocation, which is more beneficial on RV32 than RV64. cm.push allocates multiples of 16 bytes, but only uses a subset of those bytes for pushing callee-saved registers. Up to 12 (rv32) or 8 (rv64) bytes are left unused, depending on how many registers are pushed. Before this change, we told LLVM that the entire allocation was used, by creating a fixed stack object which covered the whole allocation. This change instead gives an accurate extent to the fixed stack object, to only cover the registers that have been pushed. This allows the PrologEpilogInserter to use any unused bytes for spills. Potentially this saves an extra move of the stack pointer after the push, because the push can allocate up to 48 more bytes than it needs for registers. We cannot do the same change for save/restore, because the restore routines restore in batches of `stackalign/(xlen/8)` registers, and we don't want to clobber the saved values of registers that we didn't tell the compiler we were saving/restoring - for instance `__riscv_restore_0` is used by the compiler when it only wants to save `ra`, but will end up restoring `ra` and `s0`.
Alive2: https://alive2.llvm.org/ce/z/6zLAYp Note: We can also apply this fix to the logic below (`if (Mask & AMask_NotAllOnes)`), but it seems unreachable.
… (NFC) (#126175) I suggested using a lambda in #126171 but @jasonmolenda missed it.
The current legality check for folding with EVL has incomplete verification for VF. This patch fixes the VF check, ensuring that tail folding with EVL is enabled only when a scalable VF is available. This allows loops that prefer tail folding with EVL but cannot use scalable VF vectorization to still be vectorized using a fixed VF, rather than abandoning vectorization entirely.
The config is currently not movable and because there are constructors the default move won't be generated, which prevents it from being moved. Also, it is not copyable because of the unique_ptr. This PR adds move constructor to allow moving it.
This was ultimately working around bugs in subregister handling in peephole-opt. In the common case, it would give up on folding anything into a subregister extract copy.
…125642) RISCV Zicfilp/Zicfiss extensions uses the `.note.gnu.property` section to store flags indicating the adoption of features based on these extensions. This patch enables the llvm-readobj/llvm-readelf tools to dump these flags with the `--note` flag.
…lues. The getBootstrapMap, getBootstrapMapValue, getBootstrapSymbolsMap, and getBootstrapSymbols methods forward to their respective counterparts in ExecutorProcessControl, similar to the callWrapper functions. These methods will be used to simplify an upcoming patch that accesses the bootstrap values.
…, LLJIT. The system libunwind on older Darwins does not support JIT registration of compact-unwind. Since the CompactUnwindManager utility discards redundant eh-frame FDEs by default we need to remove the compact-unwind section first when targeting older libunwinds in order to preserve eh-frames. While LLJIT was already doing this as of eae6d6d, MachOPlatform was not. This was causing buildbot failures in the ORC runtime (e.g. in https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA/3479/). This patch updates both LLJIT and MachOPlatform to check a bootstrap value, "darwin-use-ehframes-only", to determine whether to forcibly preserve eh-frame sections. If this value is present and set to true then compact-unwind sections will be discarded, causing eh-frames to be preserved. If the value is absent or set to false then compact-unwind will be used and redundant FDEs in eh-frames discarded (FDEs that are needed by the compact-unwind section are always preserved). rdar://143895614
The C++ standard prohibits this implicit destructor call, leading to incorrect reports from clang-analyzer. This causes projects that use std::option (including llvm) to fail the cplusplus.NewDelete test incorrectly when run through the analyzer. Fixes #119415
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] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )