Pull changes from latest main of upstream llvm/llvm-project #1
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
The CERT rule ERR33-C can be modeled partially by the existing check 'bugprone-unused-return-value'. The existing check is reused with a fixed set of checked functions. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D112409
We may want to restrict the detected platforms to only `x86_64` and `aarch64`. There are still custom detection in api.td but I don't think we can handle these: - config/linux/api.td:205 - config/linux/api.td:199 Differential Revision: https://reviews.llvm.org/D112818
This is needed after fd41738
Rely on the hasOperation() instead - as commented on D77804, the mid-term intention is to recognise rotate/funnel-by-constant pre-legalization to help avoid SimplifyDemandedBits regressions.
If the type of a funnel shift needs to be expanded, expand it to two funnel shifts instead of regular shifts. For constant shifts, this doesn't make much difference, but for variable shifts it allows a more optimal lowering. Also use the optimized funnel shift lowering for rotates. Alive2: https://alive2.llvm.org/ce/z/TvHDB- / https://alive2.llvm.org/ce/z/yzPept (Branched from D108058 as getting this completed should help unlock some other WIP patches). Original Patch: @efriedma (Eli Friedman) Differential Revision: https://reviews.llvm.org/D112443
ArrayRef doesn't take ownership.
A callee save may be live (specifically X1) on entry and so a spill should not mark it killed. Differential Revision: https://reviews.llvm.org/D111285
…plat vector. Fold (srl (mul (zext i32:$a to i64), i64:c), 32) -> (mulhu $a, $b), if c can truncate to i32 without loss. Reviewed By: frasercrmck, craig.topper, RKSimon Differential Revision: https://reviews.llvm.org/D108129
Inserting a symbol into a SymbolTable may lead to the name of the symbol being changed in order to ensure uniqueness of symbol names in the table. Return this new name to spare the caller the need to extract it from the symbol operation. Depends On D112700 Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D112886
Symbol tables are a largely useful top-level IR construct, for example, they make it easy to access functions in a module by name instead of traversing the list of module's operations to find the corresponding function. Depends On D112886 Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D112821
Fixes: https://bugs.llvm.org/show_bug.cgi?id=52380 Differential Revision: https://reviews.llvm.org/D112990
…ations Back in the mists of time, the CXXRecordDecl for the injected-class-name was a redecl of the outer class itself. This got changed in 470c454, but only for plain classes: class template instantation was still detecting the injected-class-name in the template body and marking its instantiation as a redecl. This causes some subtle inconsistent behavior between the two, e.g. hasDefinition() returns true for Foo<int>::Foo but false for Bar::Bar. This is the root cause of PR51912. Differential Revision: https://reviews.llvm.org/D112765
Previously, if accidentally multiple checkers `eval::Call`-ed the same `CallEvent`, in debug builds the analyzer detected this and crashed with the message stating this. Unfortunately, the message did not state the offending checkers violating this invariant. This revision addresses this by printing a more descriptive message before aborting. Reviewed By: martong Differential Revision: https://reviews.llvm.org/D112889
…ntrinsics. The scalarizer pass seems to be inserting instructions in-between PHI nodes or debug intrinsics that end up staying at the end of the pass, resulting in malformed IR and violating assumptions. This patch adds a check to make sure the `extractelement` instructions that it adds are correctly placed after all PHI nodes and debug intrinsics. Patch by vettoreldaniele. Reviewed By: bjope Differential Revision: https://reviews.llvm.org/D112472
We'd like to take a progressive approach towards Fconvolution op CodeGen, by 1) tiling it to fit compute hierarchy first, and then 2) tiling along window dimensions with size 1 to reduce the problem to be matmul-like. After that, we can 3) downscale high-D convolution ops to low-D by removing the size-1 window dimensions. The final step would be 4) vectorizing the low-D convolution op directly. We have patterns for 1), 2), and 4). This commit adds a pattern for 3) for `linalg.conv_2d_nhwc_hwcf` ops as a starter. Supporting other high-D convolution ops should be similar and mechanical. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D112928
This patch implements __builtin_reduce_max and __builtin_reduce_min as
specified in D111529.
The order of operations does not matter for min or max reductions and
they can be directly lowered to the corresponding
llvm.vector.reduce.{fmin,fmax,umin,umax,smin,smax} intrinsic calls.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D112001
…_LOAD helper. NFCI. Reduce width of X86ISD::SUBV_BROADCAST_LOAD node.
The tests diffs are logically equivalent, and so this is generally NFC, but this makes the code match the code comment. It should also be more efficient. If we choose the 'not' operand (rather than the 'not' instruction) as the select condition, then we don't have to invert the select condition/operands as a subsequent transform.
Silence the warning. Differential Revision: https://reviews.llvm.org/D113018
Header "llvm/Transforms/Scalar/SimpleLoopUnswitch.h" is currently included twice. This commit removes the duplicate 'include' line. Previous commit 693eedb seems to have mistakenly added the duplicate 'include'. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D112979
This is a new draft of D28234. I previously did the unorthodox thing of pushing to it when I wasn't the original author, but since this version - Uses `GNUInstallDirs`, rather than mimics it, as the original author was hesitant to do but others requested. - Is much broader, effecting many more projects than LLVM itself. I figured it was time to make a new revision. I am using this patch (and many back-ports) as the basis of NixOS/nixpkgs#111487 for my distro (NixOS). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful. --- As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. For example `LLVM_LIBDIR_SUFFIX`, or `COMPILER_RT_INSTALL_PATH`. Because it's not quite clear yet what to do about those, we are holding off on changing libdirs and `compiler-rt`. for this initial PR. --- On the advice of @lebedev.ri, I am splitting this up a bit per subproject, starting with LLVM. To allow it to be more easily reviewed. This and the subsequent patch must be landed together, as this will not build alone. But the rest can be landed on their own. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D100810
These aren't currently matched against unmasked vector load instructions. A patch to fix that will come later.
In the added cases we have two congruent IVs. IndVars widens at least one of them. If they are both widened, then one of them is erased as they stay congruent after widening. However if only one IV is widened, the other one stays in the loop. We can simply erase the narrow IV and replace its uses with truncates of the widest IV.
Ensure that the destination slot exists in this case. This addresses PR51484.
…eport plugin tests This patch removes unnecessary comments in the flang-omp-report plugin tests which can be implied from the file name and run command. Reviewed By: awarzynski Differential Revision: https://reviews.llvm.org/D112817
This allows shipping individual functions without also having to provide `memcpy` at the expense of bigger functions. Next is to use this `inlined_memcpy` in: - loader/linux/x86_64/start.cpp - src/string/memmove.cpp - src/string/mempcpy.cpp - src/string/strcpy.cpp - src/string/strdup.cpp - src/string/strndup.cpp Differential Revision: https://reviews.llvm.org/D113097
Similar to D113097 although not strictly necessary for now. It helps keeping the same structure for all memory functions. Differential Revision: https://reviews.llvm.org/D113103
This allows shipping individual functions without also having to provide memset or bzero at the expense of bigger functions. Similar to D113097. Differential Revision: https://reviews.llvm.org/D113108
Reviewed By: labath Differential Revision: https://reviews.llvm.org/D113176
Function specialisation was running at all optimisation levels (if enabled on the command line, it is not on by default). That was an oversight and not something we want to do. Function specialisation duplicates functions when it triggers, so the backend is processing more functions/instructions resulting in compile-time increases, which seems more appropriate with -O3 and inline with GCC. Please note that since function specialisation is not enabled by default, this didn't require updating any pass manager tests. Differential Revision: https://reviews.llvm.org/D112129
…s enabled https://reviews.llvm.org/D108392 Signed-off-by: Kevin Petit <[email protected]>
Those nullptr checks are after we already accessed the pointer. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D113175
In a "Worksharing-loop construct", one can add a nowait clause at the end of the loop (i.e. at the loop tail). This clause wasn't associated with the corresponding loop when originally worked on in flang-omp-report. Note that this refers to parsing and parse-tree generation. To work around it, it was needed to track such clauses and the loops. This should no longer be required (and in fact no longer works) and so was removed. This results in 'curLoopLogRecord' and 'loopLogRecordStack' and all references to them being removed. This also allows for 'constructClauses' to be swapped from std::deque to llvm::SmallVector. Lastly a new test has been added testing the "nowait" clauses in a variety of ways. Reviewed By: awarzynski, kiranchandramohan Differential Revision: https://reviews.llvm.org/D112217
I noticed that, while go-to-def works on cases like:
namespace ns {
template<typename T> struct Foo {};
}
using ::ns::Fo^o;
it only works because of the FileIndex. We can get definition location
directly from AST too.
Differential Revision: https://reviews.llvm.org/D113029
This interface should not have existed in the first place, let alone be a public member. It allows calling `ElementCount::get(..)->getValue()`, which is ambiguous. The interfaces to be used are either getFixedValue() or getKnownMinValue().
Summary: Remove unused function from print-changed=dot-cfg code to silence a gcc compiler warning. Author: Jamie Schmeiser <[email protected]> Reviewed By: uabelho(Mikael Holmen) Differential Revision: https://reviews.llvm.org/D113188
In preparation for D112453. Fix numbering of tests for [over.built]: 15->16, 16->17.
On Armv6-M the branch may not able to reach the _Unwind_Resume function because it's relocation(R_ARM_THM_JUMP11) is in -2048, 2047 range only. Reviewed By: chill, stuij, lenary Differential Revision: https://reviews.llvm.org/D113181
These relocations have been removed from the psABI doc in riscv-non-isa/riscv-elf-psabi-doc#199. This patch simply updates llvm/include/llvm/BinaryFormat/ELFRelocs/RISCV.def to match. Differential Revision: https://reviews.llvm.org/D112999
|
I took care of this from the command line via: |
sbc100
pushed a commit
that referenced
this pull request
Dec 30, 2021
In the latest Linux kernels synchronous tag faults include the tag bits in their address. This change adds logical and allocation tags to the description of synchronous tag faults. (asynchronous faults have no address) Process 1626 stopped * thread #1, name = 'a.out', stop reason = signal SIGSEGV: sync tag check fault (fault address: 0x900fffff7ff9010 logical tag: 0x9 allocation tag: 0x0) This extends the existing description and will show as much as it can on the rare occasion something fails. This change supports AArch64 MTE only but other architectures could be added by extending the switch at the start of AnnotateSyncTagCheckFault. The rest of the function is generic code. Tests have been added for synchronous and asynchronous MTE faults. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D105178 (cherry picked from commit d510b5f)
sbc100
pushed a commit
that referenced
this pull request
Dec 30, 2021
This patch re-introduces the fix in the commit llvm@66b0cebf7f736 by @yrnkrn > In DwarfEHPrepare, after all passes are run, RewindFunction may be a dangling > > pointer to a dead function. To make sure it's valid, doFinalization nullptrs > RewindFunction just like the constructor and so it will be found on next run. > > llvm-svn: 217737 It seems that the fix was not migrated to `DwarfEHPrepareLegacyPass`. This patch also updates `llvm/test/CodeGen/X86/dwarf-eh-prepare.ll` to include `-run-twice` to exercise the cleanup. Without this patch `llvm-lit -v llvm/test/CodeGen/X86/dwarf-eh-prepare.ll` fails with ``` -- Testing: 1 tests, 1 workers -- FAIL: LLVM :: CodeGen/X86/dwarf-eh-prepare.ll (1 of 1) ******************** TEST 'LLVM :: CodeGen/X86/dwarf-eh-prepare.ll' FAILED ******************** Script: -- : 'RUN: at line 1'; /home/arakaki/build/llvm-project/main/bin/opt -mtriple=x86_64-linux-gnu -dwarfehprepare -simplifycfg-require-and-preserve-domtree=1 -run-twice < /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -S | /home/arakaki/build/llvm-project/main/bin/FileCheck /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -- Exit Code: 2 Command Output (stderr): -- Referencing function in another module! call void @_Unwind_Resume(i8* %ehptr) #1 ; ModuleID = '<stdin>' void (i8*)* @_Unwind_Resume ; ModuleID = '<stdin>' in function simple_cleanup_catch LLVM ERROR: Broken function found, compilation aborted! PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/arakaki/build/llvm-project/main/bin/opt -mtriple=x86_64-linux-gnu -dwarfehprepare -simplifycfg-require-and-preserve-domtree=1 -run-twice -S 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'Module Verifier' on function '@simple_cleanup_catch' #0 0x000056121b570a2c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Unix/Signals.inc:569:0 #1 0x000056121b56eb64 llvm::sys::RunSignalHandlers() /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Signals.cpp:97:0 #2 0x000056121b56f28e SignalHandler(int) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Unix/Signals.inc:397:0 #3 0x00007fc7e9b22980 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12980) #4 0x00007fc7e87d3fb7 raise /build/glibc-S7xCS9/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 #5 0x00007fc7e87d5921 abort /build/glibc-S7xCS9/glibc-2.27/stdlib/abort.c:81:0 #6 0x000056121b4e1386 llvm::raw_svector_ostream::raw_svector_ostream(llvm::SmallVectorImpl<char>&) /home/arakaki/repos/watch/llvm-project/llvm/include/llvm/Support/raw_ostream.h:674:0 #7 0x000056121b4e1386 llvm::report_fatal_error(llvm::Twine const&, bool) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/ErrorHandling.cpp:114:0 #8 0x000056121b4e1528 (/home/arakaki/build/llvm-project/main/bin/opt+0x29e3528) #9 0x000056121adfd03f llvm::raw_ostream::operator<<(llvm::StringRef) /home/arakaki/repos/watch/llvm-project/llvm/include/llvm/Support/raw_ostream.h:218:0 FileCheck error: '<stdin>' is empty. FileCheck command line: /home/arakaki/build/llvm-project/main/bin/FileCheck /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -- ******************** ******************** Failed Tests (1): LLVM :: CodeGen/X86/dwarf-eh-prepare.ll Testing Time: 0.22s Failed: 1 ``` Reviewed By: loladiro Differential Revision: https://reviews.llvm.org/D110979 (cherry picked from commit e8806d7)
aheejin
pushed a commit
that referenced
this pull request
Nov 14, 2023
…e defintion if available (llvm#71004)" This reverts commit ef3feba. This caused an LLDB test failure on Linux for `lang/cpp/symbols/TestSymbols.test_dwo`: ``` make: Leaving directory '/home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex/lang/cpp/symbols/TestSymbols.test_dwo' runCmd: expression -- D::i PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. HandleCommand(command = "expression -- D::i") 1. <user expression 0>:1:4: current parser token 'i' 2. <lldb wrapper prefix>:44:1: parsing function body '$__lldb_expr' 3. <lldb wrapper prefix>:44:1: in compound statement ('{}') Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 _lldb.cpython-39-x86_64-linux-gnu.so 0x00007fbcfcb08b87 1 _lldb.cpython-39-x86_64-linux-gnu.so 0x00007fbcfcb067ae 2 _lldb.cpython-39-x86_64-linux-gnu.so 0x00007fbcfcb0923f 3 libpthread.so.0 0x00007fbd07ab7140 ``` And a failure in `TestCallStdStringFunction.py` on Linux aarch64: ``` -- Exit Code: -11 Command Output (stdout): -- lldb version 18.0.0git (https://github.com/llvm/llvm-project.git revision ef3feba) clang revision ef3feba llvm revision ef3feba -- Command Output (stderr): -- PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. HandleCommand(command = "expression str") 1. <lldb wrapper prefix>:45:34: current parser token ';' 2. <lldb wrapper prefix>:44:1: parsing function body '$__lldb_expr' 3. <lldb wrapper prefix>:44:1: in compound statement ('{}') #0 0x0000ffffb72a149c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_[lldb.cpython-38-aarch64-linux-gnu.so](http://lldb.cpython-38-aarch64-linux-gnu.so/)+0x58c749c) #1 0x0000ffffb729f458 llvm::sys::RunSignalHandlers() (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_[lldb.cpython-38-aarch64-linux-gnu.so](http://lldb.cpython-38-aarch64-linux-gnu.so/)+0x58c5458) #2 0x0000ffffb72a1bd0 SignalHandler(int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_[lldb.cpython-38-aarch64-linux-gnu.so](http://lldb.cpython-38-aarch64-linux-gnu.so/)+0x58c7bd0) #3 0x0000ffffbdd9e7dc (linux-vdso.so.1+0x7dc) #4 0x0000ffffb71799d8 lldb_private::plugin::dwarf::SymbolFileDWARF::FindGlobalVariables(lldb_private::ConstString, lldb_private::CompilerDeclContext const&, unsigned int, lldb_private::VariableList&) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_[lldb.cpython-38-aarch64-linux-gnu.so](http://lldb.cpython-38-aarch64-linux-gnu.so/)+0x579f9d8) #5 0x0000ffffb7197508 DWARFASTParserClang::FindConstantOnVariableDefinition(lldb_private::plugin::dwarf::DWARFDIE) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_[lldb.cpython-38-aarch64-linux-gnu.so](http://lldb.cpython-38-aarch64-linux-gnu.so/)+0x57bd508) ```
aheejin
pushed a commit
that referenced
this pull request
Nov 14, 2023
…ooking options for a custom subcommand (llvm#71975) …ooking options for a custom subcommand. (llvm#71776)" This reverts commit b88308b. The build-bot is unhappy (https://lab.llvm.org/buildbot/#/builders/186/builds/13096), `GroupingAndPrefix` fails after `TopLevelOptInSubcommand` (the newly added test). Revert while I look into this (might be related with test sharding but not sure) ``` [----------] 3 tests from CommandLineTest [ RUN ] CommandLineTest.TokenizeWindowsCommandLine2 [ OK ] CommandLineTest.TokenizeWindowsCommandLine2 (0 ms) [ RUN ] CommandLineTest.TopLevelOptInSubcommand [ OK ] CommandLineTest.TopLevelOptInSubcommand (0 ms) [ RUN ] CommandLineTest.GroupingAndPrefix #0 0x00ba8118 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x594118) #1 0x00ba5914 llvm::sys::RunSignalHandlers() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x591914) #2 0x00ba89c4 SignalHandler(int) (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5949c4) #3 0xf7828530 __default_sa_restorer /build/glibc-9MGTF6/glibc-2.31/signal/../sysdeps/unix/sysv/linux/arm/sigrestorer.S:67:0 #4 0x00af91f0 (anonymous namespace)::CommandLineParser::ResetAllOptionOccurrences() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x4e51f0) #5 0x00af8e1c llvm::cl::ResetCommandLineParser() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x4e4e1c) #6 0x0077cda0 (anonymous namespace)::CommandLineTest_GroupingAndPrefix_Test::TestBody() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x168da0) #7 0x00bc5adc testing::Test::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5b1adc) #8 0x00bc6cc0 testing::TestInfo::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5b2cc0) #9 0x00bc7880 testing::TestSuite::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5b3880) #10 0x00bd7974 testing::internal::UnitTestImpl::RunAllTests() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5c3974) #11 0x00bd6ebc testing::UnitTest::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5c2ebc) #12 0x00bb1058 main (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x59d058) #13 0xf78185a4 __libc_start_main /build/glibc-9MGTF6/glibc-2.31/csu/libc-start.c:342:3 ```
aheejin
pushed a commit
that referenced
this pull request
Nov 14, 2024
```
UBSan-Standalone-sparc :: TestCases/Misc/Linux/diag-stacktrace.cpp
```
`FAIL`s on 32 and 64-bit Linux/sparc64 (and on Solaris/sparcv9, too: the
test isn't Linux-specific at all). With
`UBSAN_OPTIONS=fast_unwind_on_fatal=1`, the stack trace shows a
duplicate innermost frame:
```
compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:31: runtime error: execution reached the end of a value-returning function without returning a value
#0 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35
#1 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35
#2 0x7003a714 in g() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:17:38
```
which isn't seen with `fast_unwind_on_fatal=0`.
This turns out to be another fallout from fixing
`__builtin_return_address`/`__builtin_extract_return_addr` on SPARC. In
`sanitizer_stacktrace_sparc.cpp` (`BufferedStackTrace::UnwindFast`) the
`pc` arg is the return address, while `pc1` from the stack frame
(`fr_savpc`) is the address of the `call` insn, leading to a double
entry for the innermost frame in `trace_buffer[]`.
This patch fixes this by moving the adjustment before all uses.
Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`
(with the `ubsan/TestCases/Misc/Linux` tests enabled).
(cherry picked from commit 3368a32)
aheejin
pushed a commit
that referenced
this pull request
May 1, 2025
…ible (llvm#123752) This patch adds a new option `-aarch64-enable-zpr-predicate-spills` (which is disabled by default), this option replaces predicate spills with vector spills in streaming[-compatible] functions. For example: ``` str p8, [sp, #7, mul vl] // 2-byte Folded Spill // ... ldr p8, [sp, #7, mul vl] // 2-byte Folded Reload ``` Becomes: ``` mov z0.b, p8/z, #1 str z0, [sp] // 16-byte Folded Spill // ... ldr z0, [sp] // 16-byte Folded Reload ptrue p4.b cmpne p8.b, p4/z, z0.b, #0 ``` This is done to avoid streaming memory hazards between FPR/vector and predicate spills, which currently occupy the same stack area even when the `-aarch64-stack-hazard-size` flag is set. This is implemented with two new pseudos SPILL_PPR_TO_ZPR_SLOT_PSEUDO and FILL_PPR_FROM_ZPR_SLOT_PSEUDO. The expansion of these pseudos handles scavenging the required registers (z0 in the above example) and, in the worst case spilling a register to an emergency stack slot in the expansion. The condition flags are also preserved around the `cmpne` in case they are live at the expansion point.
aheejin
pushed a commit
that referenced
this pull request
May 1, 2025
`clang-repl --cuda` was previously crashing with a segmentation fault, instead of reporting a clean error ``` (base) anutosh491@Anutoshs-MacBook-Air bin % ./clang-repl --cuda #0 0x0000000111da4fbc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x150fbc) #1 0x0000000111da31dc llvm::sys::RunSignalHandlers() (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x14f1dc) #2 0x0000000111da5628 SignalHandler(int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x151628) #3 0x000000019b242de4 (/usr/lib/system/libsystem_platform.dylib+0x180482de4) #4 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0) #5 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0) #6 0x0000000107f6bac8 clang::Interpreter::createWithCUDA(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x2173ac8) #7 0x000000010206f8a8 main (/opt/local/libexec/llvm-20/bin/clang-repl+0x1000038a8) #8 0x000000019ae8c274 Segmentation fault: 11 ``` The underlying issue was that the `DeviceCompilerInstance` (used for device-side CUDA compilation) was never initialized with a `Sema`, which is required before constructing the `IncrementalCUDADeviceParser`. https://github.com/llvm/llvm-project/blob/89687e6f383b742a3c6542dc673a84d9f82d02de/clang/lib/Interpreter/DeviceOffload.cpp#L32 https://github.com/llvm/llvm-project/blob/89687e6f383b742a3c6542dc673a84d9f82d02de/clang/lib/Interpreter/IncrementalParser.cpp#L31 Unlike the host-side `CompilerInstance` which runs `ExecuteAction` inside the Interpreter constructor (thereby setting up Sema), the device-side CI was passed into the parser uninitialized, leading to an assertion or crash when accessing its internals. To fix this, I refactored the `Interpreter::create` method to include an optional `DeviceCI` parameter. If provided, we know we need to take care of this instance too. Only then do we construct the `IncrementalCUDADeviceParser`. (cherry picked from commit 21fb19f)
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.
LLVM 13.0.0 got released on 4 Oct 2021
It would be nice to update used parts like libcxx, libcxxabi, compiler-rt.
emscripten-core/emscripten#15396