summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Bring back mach_absolute_time implementation of steady_clockllvm_plex_11.0.1Louis Dionne2021-02-011-0/+59
| | | | | | This is meant to unblock Chrome, as discussed in https://llvm.org/D74489. Differential Revision: https://reviews.llvm.org/D95177
* [libcxx] Avoid overflows in the windows __libcpp_steady_clock_now()Martin Storsjö2021-02-012-1/+6
| | | | | | | | | | | | | | | | | | | As freq.QuadValue can be in the range of 10000000 to 19200000, the multiplication before division makes the calculation overflow and wrap to negative values every 16-30 minutes. Instead count the whole seconds separately before adding the scaled fractional seconds. Add a testcase for steady_clock to check that the values returned for now() compare as bigger than the zero time origin; this corresponds to a testcase in Qt [1] [2] (that failed spuriously due to this). [1] https://bugreports.qt.io/browse/QTBUG-89539 [2] https://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/corelib/kernel/qdeadlinetimer/tst_qdeadlinetimer.cpp?id=f8de5e54022b8b7471131b7ad55c83b69b2684c0#n569 Differential Revision: https://reviews.llvm.org/D93456
* [libc++] NFCI: Refactor chrono.cpp to make it easier to support new platformsLouis Dionne2021-02-011-38/+47
| | | | Also simplify a few conditionals along the way for readability.
* [libc++] Check _LIBCPP_USE_CLOCK_GETTIME before using clock_gettimeHafiz Abid Qadeer2021-02-011-8/+8
| | | | | | | | | | | | | The clock_gettime function is available when _POSIX_TIMERS is defined. We check for this and set _LIBCPP_USE_CLOCK_GETTIME accordingly since 59b3102739c. But check for _LIBCPP_USE_CLOCK_GETTIME was removed in babd3aefc91. As a result, code is now trying to use clock_gettime even on platforms where it is not available and it is causing build failure with newlib. This patch restores the checks to fix this. Differential Revision: https://reviews.llvm.org/D88825
* Add support for -delete_all_rpaths to llvm-install-name-toolTobias Hieta2020-12-294-1/+16
|
* roll back some optionsTobias Hieta2020-12-291-1/+1
|
* LTO: Pass more aggresive optimization optionsTobias Hieta2020-12-291-2/+2
|
* [AArch64][GlobalISel] Promote scalar G_SHL constant shift amounts to s64.llvmorg-11.0.1-rc2llvmorg-11.0.1Amara Emerson2020-12-185-20/+28
| | | | | | | | | | | This was supposed to be done in the first place as is currently the case for G_ASHR and G_LSHR but was forgotten when the original shift legalization overhaul was done last year. This was exposed because we started falling back on s32 = s32, s64 SHLs due to a recent combiner change. Gives a very minor (0.1%) code size -O0 improvement on consumer-typeset.
* [AArch64][GlobalISel] Use the look-through constant helper for the shift ↵Amara Emerson2020-12-182-8/+7
| | | | | | s32->s64 custom legalization. Almost NFC, except it catches more cases and gives a 0.1% CTMark -O0 size win.
* [CMake] Avoid __FakeVCSRevision.h with no git repositoryJonas Hahnfeld2020-12-172-1/+9
| | | | | | | | | | | | | | | Set the return variable to "" in find_first_existing_vc_file to say that there is a repository, but no file to depend on. This works transparently for all other callers that handle undefinedness and equality to an empty string the same way. Use the knowledge to avoid depending on __FakeVCSRevision.h if there is no git repository at all (for example when building a release) as there is no point in regenerating an empty VCSRevision.h. Differential Revision: https://reviews.llvm.org/D92718 (cherry picked from commit 6e890ec7beb0874464a0af9f84e41a987f968b23)
* Don't error for zero-length arange entriesJames Henderson2020-12-162-11/+67
| | | | | | | | | | | | | | | | | | Although the DWARF specification states that .debug_aranges entries can't have length zero, these can occur in the wild. There's no particular reason to enforce this part of the spec, since functionally they have no impact. The patch removes the error and introduces a new warning for premature terminator entries which does not stop parsing. This is a relanding of cb3a598c87db, adding the missing obj2yaml part that was needed. Fixes https://bugs.llvm.org/show_bug.cgi?id=46805. See also https://reviews.llvm.org/D71932 which originally introduced the error. Reviewed by: ikudrin, dblaikie, Higuoxing Differential Revision: https://reviews.llvm.org/D85313
* [AArch64][GlobalISel] Narrow 128-bit regs to 64-bit regs in emitTestBitJessica Paquette2020-12-154-77/+67
| | | | | | | | | | | | | | | | | | | | | When we have a 128-bit register, emitTestBit would incorrectly narrow to 32 bits always. If the bit number was > 32, then we would need a TB(N)ZX. This would cause a crash, as we'd have the wrong register class. (PR48379) This generalizes `narrowExtReg` into `moveScalarRegClass`. This also allows us to remove `widenGPRBankRegIfNeeded` entirely, since `selectCopy` correctly handles SUBREG_TO_REG etc. This does create some codegen changes (since `selectCopy` uses the `all` regclass variants). However, I think that these will likely be optimized away, and we can always improve the `selectCopy` code. It looks like we should revisit `selectCopy` at this point, and possibly refactor it into at least one `emit` function. Differential Revision: https://reviews.llvm.org/D92707 (cherry picked from commit 195a7af0abb26915f962462f69c0f17e3835f78b)
* [AArch64][GlobalISel] Look through a G_ZEXT when trying to match ↵Amara Emerson2020-12-152-12/+61
| | | | | | | | | | | | shift-extended register offsets. The G_ZEXT in these cases seems to actually come from a combine that we do but SelectionDAG doesn't. Looking through it allows us to match "uxtw #2" addressing modes. Differential Revision: https://reviews.llvm.org/D91475 (cherry picked from commit 0b6090699ab542cde24be1565b4d97dbad153cba)
* [Support] PR42623: Avoid setting the delete-on-close bit if a TempFile ↵Ronald Wampler2020-12-151-0/+14
| | | | | | | | | | | | | | | doesn't reside on a local drive On Windows, after commit 881ba104656c40098d4bc90c52613c08136f0fe1, tools using TempFile would error with "bad file descriptor" when writing the file on a network drive. It appears that setting the delete-on-close bit via SetFileInformationByHandle/FileDispositionInfo prevented it from accessing the file on network drives, and although using FILE_DISPOSITION_INFO seems to work, it causes other troubles. Differential Revision: https://reviews.llvm.org/D81803 (cherry picked from commit 79657e2339b58bc01fe1b85a448bb073d57d90bb)
* [Support][Windows] Fix incorrect GetFinalPathNameByHandleW() return value ↵Aleksandr Platonov2020-12-151-4/+3
| | | | | | | | | | | | | | | | | | | check in realPathFromHandle() `GetFinalPathNameByHandleW(,,N,)` returns: - `< N` on success (this value does not include the size of the terminating null character) - `>= N` if buffer is too small (this value includes the size of the terminating null character) So, when `N == Buffer.capacity() - 1`, we need to resize buffer if return value is > `Buffer.capacity() - 2`. Also, we can set `N` to `Buffer.capacity()`. Thus, without this patch `realPathFromHandle()` returns unfilled buffer when length of the final path of the file is equal to `Buffer.capacity()` or `Buffer.capacity() - 1`. Reviewed By: andrewng, amccarth Differential Revision: https://reviews.llvm.org/D86564 (cherry picked from commit ceffd6993c350b57f43cec3b6371b159fc4a3149)
* Don't reject calls to MinGW's unusual _setjmp declaration.Richard Smith2020-12-144-23/+52
| | | | | | We now recognize this function as a builtin despite it having an unexpected number of parameters; make sure we don't enforce that it has only 1 argument for its 2 parameters.
* Recognize setjmp and friends as builtins even if jmp_buf is not declared yet.Richard Smith2020-12-146-32/+116
| | | | | | | This happens in glibc's headers. It's important that we recognize these functions so that we can mark them as returns_twice. Differential Revision: https://reviews.llvm.org/D88518
* [Sema] Handle objc_super special lookup when checking builtin compatibilityRaul Tambre2020-12-142-0/+9
| | | | | | | objc_super is special and needs LookupPredefedObjCSuperType() called before performing builtin type comparisons. This fixes an error when compiling macOS headers. A test is added. Differential Revision: https://reviews.llvm.org/D87917
* [Sema] Introduce BuiltinAttr, per-declaration builtin-nessRaul Tambre2020-12-1419-216/+193
| | | | | | | | | | | | | | | | | | | | | | | Instead of relying on whether a certain identifier is a builtin, introduce BuiltinAttr to specify a declaration as having builtin semantics. This fixes incompatible redeclarations of builtins, as reverting the identifier as being builtin due to one incompatible redeclaration would have broken rest of the builtin calls. Mostly-compatible redeclarations of builtins also no longer have builtin semantics. They don't call the builtin nor inherit their attributes. A long-standing FIXME regarding builtins inside a namespace enclosed in extern "C" not being recognized is also addressed. Due to the more correct handling attributes for builtin functions are added in more places, resulting in more useful warnings. Tests are updated to reflect that. Intrinsics without an inline definition in intrin.h had `inline` and `static` removed as they had no effect and caused them to no longer be recognized as builtins otherwise. A pthread_create() related test is XFAIL-ed, as it relied on it being recognized as a builtin based on its name. The builtin declaration syntax is too restrictive and doesn't allow custom structs, function pointers, etc. It seems to be the only case and fixing this would require reworking the current builtin syntax, so this seems acceptable. Fixes PR45410. Reviewed By: rsmith, yutsumi Differential Revision: https://reviews.llvm.org/D77491
* Stop ExtractTypeForDeductionGuide from recursing on TypeSourceInfoErich Keane2020-12-142-2/+41
| | | | | | | | | As reported in PR48177, the type-deduction extraction ends up going into an infinite loop when the type referred to has a recursive definition. This stops recursing and just substitutes the type-source-info the TypeLocBuilder identified when transforming the base. (cherry picked from commit 1c98f984105e552daa83ed8e92c61fba0e401410)
* [MC][ELF] Accept abbreviated form with sh_flags and sh_entsizeTobias Burnus2020-12-143-2/+19
| | | | | | | | | | | | | | | | | | | | D73999 / commit 75af9da755721123e62b45cd0bc0c5e688a9722a added for LLVM 11 a check that sh_flags and sh_entsize (and sh_type) changes are an error, in line with GNU assembler. However, GNU assembler accepts and GCC generates an abbreviated form: while the first .section contains the flags and entsize, subsequent sections simply contain the name without repeating entsize or flags. Do likewise for better compatibility. See https://bugs.llvm.org/show_bug.cgi?id=48201 Reviewed By: jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D92052 (cherry picked from commit 1deff4009e0ae661b03682901bf6932297ce7ea1)
* [KernelAddressSanitizer] Fix globals exclusion for indirect aliasesMarco Elver2020-12-142-14/+39
| | | | | | | | | | | | | | GlobalAlias::getAliasee() may not always point directly to a GlobalVariable. In such cases, try to find the canonical GlobalVariable that the alias refers to. Link: https://github.com/ClangBuiltLinux/linux/issues/1208 Reviewed By: dvyukov, nickdesaulniers Differential Revision: https://reviews.llvm.org/D92846 (cherry picked from commit c28b18af19621e6b5cca257ef7139ba93833df0c)
* [InstCombine] canonicalizeSaturatedAdd(): last fold is only valid for strict ↵Roman Lebedev2020-12-142-17/+27
| | | | | | | | | | | | | | | | | | | comparison (PR48390) We could create uadd.sat under incorrect circumstances if a select with -1 as the false value was canonicalized by swapping the T/F values. Unlike the other transforms in the same function, it is not invariant to equality. Some alive proofs: https://alive2.llvm.org/ce/z/emmKKL Based on original patch by David Green! Fixes https://bugs.llvm.org/show_bug.cgi?id=48390 Differential Revision: https://reviews.llvm.org/D92717 (cherry picked from commit e6f2a79d7aa01f8dd7f0194f97a50b480e8ede71)
* [NFC][InstCombine] Add test coverage for @llvm.uadd.sat canonicalizationRoman Lebedev2020-12-141-0/+178
| | | | | | | | | | The non-strict variants are already handled because they are canonicalized to strict variants by swapping hands in both the select and icmp, and the fold simply considers that strictness is irrelevant here. But that isn't actually true for the last pattern, as PR48390 reports. (cherry picked from commit f16320b90b8381f2e3aac1ec17f39eff06f09ea0)
* [SemaTemplate] Stop passing insertion position around during VarTemplate ↵Bruno Cardoso Lopes2020-12-142-8/+12
| | | | | | | | | | | | | | | instantiation They can get stale at use time because of updates from other recursive specializations. Instead, rely on the existence of previous declarations to add the specialization. Differential Revision: https://reviews.llvm.org/D87853 (cherry picked from commit cffb0dd54d41d8e249d2009467c4beb5b681ba26) This is a re-commit of 8ac709578067f77a7036fe50610277516fa36d50 with some modifications to avoid changing the clang API.
* [X86] Fix crash with i64 bitreverse on 32-bit targets with XOP.Craig Topper2020-12-142-0/+205
| | | | | | | | | | | | | We unconditionally marked i64 as Custom, but did not install a handler in ReplaceNodeResults when i64 isn't legal type. This leads to ReplaceNodeResults asserting. We have two options to fix this. Only mark i64 as Custom on 64-bit targets and let it expand to two i32 bitreverses which each need a VPPERM. Or the other option is to add the Custom handling to ReplaceNodeResults. This is what I went with. (cherry picked from commit 57c0c4a27575840ae0a48eb9f8455a5ed087c857)
* [lldb] Report old modules from ModuleList::ReplaceEquivalentJoseph Tremoulet2020-12-113-10/+39
| | | | | | | | | | | | | | This allows the Target to update its module list when loading a shared module replaces an equivalent one. A testcase is added which hits this codepath -- without the fix, the target reports libbreakpad.so twice in its module list. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D89157 (cherry picked from commit d20aa7ca422145fb4d07e16c1d0aa7de9e3554ea)
* [lldb] GetSharedModule: Collect old modules in SmallVectorJoseph Tremoulet2020-12-1113-101/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The various GetSharedModule methods have an optional out parameter for the old module when a file has changed or been replaced, which the Target uses to keep its module list current/correct. We've been using a single ModuleSP to track "the" old module, and this change switches to using a SmallVector of ModuleSP, which has a couple benefits: - There are multiple codepaths which may discover an old module, and this centralizes the code for how to handle multiples in one place, in the Target code. With the single ModuleSP, each place that may discover an old module is responsible for how it handles multiples, and the current code is inconsistent (some code paths drop the first old module, others drop the second). - The API will be more natural for identifying old modules in routines that work on sets, like ModuleList::ReplaceEquivalent (which I plan on updating to report old module(s) in a subsequent change to fix a bug). I'm not convinced we can ever actually run into the case that multiple old modules are found in the same GetOrCreateModule call, but I think this change makes sense regardless, in light of the above. When an old module is reported, Target::GetOrCreateModule calls m_images.ReplaceModule, which doesn't allow multiple "old" modules; the new code calls ReplaceModule for the first "old" module, and for any subsequent old modules it logs the event and calls m_images.Remove. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D89156 (cherry picked from commit 61bfc703c3d36fbefc476cd3829065d983c1c792)
* [lldb] Minidump: check for .text hash match with directoryJoseph Tremoulet2020-12-114-49/+133
| | | | | | | | | | | | | | | | | | | | | | When opening a minidump, we might discover that it reports a UUID for a module that doesn't match the build ID, but rather a hash of the .text section (according to either of two different hash functions, used by breakpad and Facebook respectively). The current logic searches for a module by filename only to check the hash; this change updates it to first search by directory+filename. This is important when the directory specified in the minidump must be interpreted relative to a user-provided sysoort, as the leaf directory won't be in the search path in that case. Also add a regression test; without this change, module validation fails because we have just the placeholder module which reports as its path the platform path in the minidump. Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D89155 (cherry picked from commit d30797b4041ffe215b92d376af60c4f26a0555ae)
* Add hashing of the .text section to ProcessMinidump.Greg Clayton2020-12-116-0/+218
| | | | | | | | Breakpad will always have a UUID for binaries when it creates minidump files. If an ELF files has a GNU build ID, it will use that. If it doesn't, it will create one by hashing up to the first 4096 bytes of the .text section. LLDB was not able to load these binaries even when we had the right binary because the UUID didn't match. LLDB will use the GNU build ID first as the main UUID for a binary and fallback onto a 8 byte CRC if a binary doesn't have one. With this fix, we will check for the Breakpad hash or the Facebook hash (a modified version of the breakpad hash that collides a bit less) and accept binaries when these hashes match. Differential Revision: https://reviews.llvm.org/D86261 (cherry picked from commit 0e6c9a6e7940a2f8ee624358d828acffdb9ccca5)
* [lldb] Normalize paths in new testJoseph Tremoulet2020-12-111-2/+3
| | | | | | | | | The minidump-sysroot test I added in commit 20f84257 compares two paths using a string comparison. This causes the Windows buildbot to fail because of mismatched forward slashes and backslashes. Use os.path.normcase to normalize before comparing. (cherry picked from commit 4a55c98fa7bee1e5ab1504db20ca4d7c8a083111)
* [lldb] Fix GetRemoteSharedModule fallback logicJoseph Tremoulet2020-12-112-4/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | When the various methods of locating the module in GetRemoteSharedModule fail, make sure we pass the original module spec to the bail-out call to the provided resolver function. Also make sure we consistently use the resolved module spec from the various success paths. Thanks to what appears to have been an accidentally inverted condition (commit 85967fa applied the new condition to a path where GetModuleSpec returns false, but should have applied it when GetModuleSpec returns true), without this fix we only pass the original module spec in the fallback if the original spec has no uuid (or has a uuid that somehow matches the resolved module's uuid despite the call to GetModuleSpec failing). This manifested as a bug when processing a minidump file with a user-provided sysroot, since in that case the resolver call was being applied to resolved_module_spec (despite resolution failing), which did not have the path of its file_spec set. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D88099 (cherry picked from commit 20f84257ac4ac54ceb5f581a6081fac6eff2a5a1)
* [Sparc] Remove cast that truncates immediate operands to 32 bits.Brad Smith2020-12-092-1/+10
| | | | | | | | | | Patch by: Mark Kettenis Test provided by Jessica Clarke. Differential Revision: https://reviews.llvm.org/D87210 (cherry picked from commit 9ae95a0f8f1bc9bd9e8eb30a5a9444fbdca5cc29)
* [LLD][COFF] Fix crash with /summary and PCH input filesTom Stellard2020-12-094-1/+191
| | | | | | | | Before this patch /summary was crashing with some .PCH.OBJ files, because tpiMap[srcIdx++] was reading at the wrong location. When the TpiSource depends on a .PCH.OBJ file, the types should be offset by the previously merged PCH.OBJ set of indices. Differential Revision: https://reviews.llvm.org/D88678 (cherry picked from commit 4140f0744fb2deccb74e77282e23ff731f67821b)
* [CUDA] Another attempt to fix early inclusion of <new> from libstdc++Artem Belevich2020-12-091-24/+22
| | | | | | | | | | | | | | Previous patch (9a465057a64dba) did not fix the problem. https://bugs.llvm.org/show_bug.cgi?id=48228 If the <new> is included too early, before CUDA-specific defines are available, just include-next the standard <new> and undo the include guard. CUDA-specific variants of operator new/delete will be declared if/when <new> is used from the CUDA source itself, when all CUDA-related macros are available. Differential Revision: https://reviews.llvm.org/D91807 (cherry picked from commit 43267929423bf768bbbcc65e47a07e37af7f4e22)
* [CUDA] Unbreak CUDA compilation with -std=c++20Artem Belevich2020-12-091-14/+24
| | | | | | | | | | | | Standard libc++ headers in stdc++ mode include <new> which picks up cuda_wrappers/new before any of the CUDA macros have been defined. We can not include CUDA headers that early, so the work-around is to define __device__ in the wrapper header itself. Differential Revision: https://reviews.llvm.org/D91807 (cherry picked from commit 9a465057a64dba8a8614424d26136f5c0452bcc3)
* [X86][AVX] Only share broadcasts of different widths from the same SDValue ↵Simon Pilgrim2020-12-092-6/+11
| | | | | | | | | | | | | | | of the same SDNode (PR48215) D57663 allowed us to reuse broadcasts of the same scalar value by extracting low subvectors from the widest type. Unfortunately we weren't ensuring the broadcasts were from the same SDValue, just the same SDNode - which failed on multiple-value nodes like ISD::SDIVREM FYI: I intend to request this be merged into the 11.x release branch. Differential Revision: https://reviews.llvm.org/D91709 (cherry picked from commit 14ae02fb3397961bb5f99a0df60622375fc1976d) Signed-off-by: Warren Ristow <warren.ristow@sony.com>
* [X86] Add broadcast merge test case for PR48215Simon Pilgrim2020-12-091-0/+75
| | | | | (cherry picked from commit 8270f8c252d7013761c54e5bf528ac3e4e3b517c) Signed-off-by: Warren Ristow <warren.ristow@sony.com>
* Fix missed SI_RETURN_TO_EPILOG in pre-emit peepholeCarl Ritson2020-12-092-8/+85
| | | | | | | | | | | | SIPreEmitPeephole does not process all terminators, which means it can fail to handle SI_RETURN_TO_EPILOG if immediately preceeded by a branch to the early exit block. Reviewed By: rampitec Differential Revision: https://reviews.llvm.org/D85872 (cherry picked from commit d538c5837a2cfedbf274133e29612da76003beed)
* [Clang][CodeGen][RISCV] Fix hard float ABI for struct with empty struct and ↵Luís Marques2020-12-092-1/+16
| | | | | | | | | | complex Fixes bug 44904. Differential Revision: https://reviews.llvm.org/D91278 (cherry picked from commit 3af354e863f553ef727967dfc091a64a11500aa5)
* [Clang][CodeGen][RISCV] Fix hard float ABI test cases with empty structLuís Marques2020-12-092-11/+8
| | | | | | | | The code seemed not to account for the field 1 offset. Differential Revision: https://reviews.llvm.org/D91270 (cherry picked from commit fa8f5bfa4e8cff042c9730320c74e97fab152ae1)
* [Clang][CodeGen][RISCV] Add hard float ABI tests with empty structLuís Marques2020-12-091-0/+37
| | | | | | | | | This patch adds tests that showcase a behavior that is currently buggy. Fix in a follow-up patch. Differential Revision: https://reviews.llvm.org/D91269 (cherry picked from commit ca93f9abdc0abc96ca8fb7999549a50aadd95caf)
* Guard `find_library(tensorflow_c_api ...)` by checking for ↵Mehdi Amini2020-12-081-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TENSORFLOW_C_LIB_PATH to be set by the user Also have CMake fails if the user provides a TENSORFLOW_C_LIB_PATH but we can't find TensorFlow at this path. At the moment the CMake script tries to figure if TensorFlow is available on the system and enables support for it. This is in general not desirable to customize build features this way and instead it is preferable to let the user opt-in explicitly into the features they want to enable. This is in line with other optional external dependencies like Z3. There are a few reasons to this but amongst others: - reproducibility: making features "magically" enabled based on whether we find a package on the system or not makes it harder to handle bug reports from users. - user control: they can't have TensorFlow on the system and build LLVM without TensorFlow right now. They also would suddenly distribute LLVM with a different set of features unknowingly just because their build machine environment would change subtly. Right now this is motivated by a user reporting build failures on their system: .../mesa-git/llvm-git/src/llvm-project/llvm/lib/Analysis/TFUtils.cpp:23:10: fatal error: tensorflow/c/c_api.h: No such file or directory 23 | #include "tensorflow/c/c_api.h" | ^~~~~~ It looks like we detected TensorFlow at configure time but couldn't set all the paths correctly. Differential Revision: https://reviews.llvm.org/D88371 (cherry picked from commit e72d792c147ee506e337401e20c0f23042cc43fe)
* Implement .variant_pcs directiveCullen Rhodes2020-12-088-0/+142
| | | | | | | | | | | | | | | | | | | A dynamic linker with lazy binding support may need to handle variant PCS function symbols specially, so an ELF symbol table marking STO_AARCH64_VARIANT_PCS [1] was added to address this. Function symbols that follow the vector PCS are marked via the .variant_pcs assembler directive, which takes a single parameter specifying the symbol name and sets the STO_AARCH64_VARIANT_PCS st_other flag in the object file. [1] https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#st-other-values Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D89138 (cherry picked from commit c87bd2d8eb378d152f2b6bde4cb088ad390a676c)
* Add fatal error for unnamed SVE variadic argumentsDavid Sherwood2020-12-086-0/+94
| | | | | | | | | | We don't currently support passing unnamed variadic SVE arguments so I've added a fatal error if we hit such cases to prevent any silent ABI issues in future. Differential Revision: https://reviews.llvm.org/D90230 (cherry picked from commit cea69fa4dcc4fcf3be62dba49ad012879d89377d)
* Add fatal error when running out of registers for SVE tuple call argumentsDavid Sherwood2020-12-084-30/+69
| | | | | | | | | | | | | | | | | | | | | When passing SVE types as arguments to function calls we can run out of hardware SVE registers. This is normally fine, since we switch to an indirect mode where we pass a pointer to a SVE stack object in a GPR. However, if we switch over part-way through processing a SVE tuple then part of it will be in registers and the other part will be on the stack. This is wrong and we'd like to avoid any silent ABI compatibility issues in future. For now, I've added a fatal error when this happens until we can get a proper fix. NOTE: Cherry-pick contains changes to remove redundant operand from min/max tests in 'llvm-ir-to-intrinsic.ll', which weren't originally part of this patch since they were removed in D85142 before this landed, but they fail otherwise. Differential Revision: https://reviews.llvm.org/D89326 (cherry picked from commit af57a0838eba528c2e5bd805d92c611435fca0d8)
* Fix unwind info relocation with large code model on AArch64Valentin Churavy2020-12-082-0/+22
| | | | | | | | | | Makes sure that the unwind info uses 64bits pcrel relocation if a large code model is specified and handle the corresponding relocation in the ExecutionEngine. This can happen with certain kernel configuration (the same as the one in https://reviews.llvm.org/D27609, found at least on the ArchLinux stock kernel and the one used on https://www.packet.net/) using the builtin JIT memory manager. Co-authored-by: Yichao Yu <yyc1992@gmail.com> Differential Revision: https://reviews.llvm.org/D27629 (cherry picked from commit 18805ea951be02fcab6e7b11c3c7d929bcf1441a)
* [GNU ObjC] Fix a regression listing methods twice.David Chisnall2020-12-032-13/+23
| | | | | | | | | | | | | Methods synthesized from declared properties were being added to the method lists twice. This came from the change to list them in the class's method list, which missed removing the place in CGObjCGNU that added them again. Reviewed By: lanza Differential Revision: https://reviews.llvm.org/D91874 (cherry picked from commit d1ed67037de6f3f44dc446784f74f0e02adec9b5)
* [HIP] Fix static-lib test CHECK bugAaron En Ye Shi2020-12-011-2/+6
| | | | | | | | | | | Fix hip test failures that were introduced by previous changes to hip-toolchain-rdc-static-lib.hip test. The .*lld.* is matching a longer string than expected. Differential Revision: https://reviews.llvm.org/D92342 (cherry picked from commit cd5897d55908827faf3e16c505bd79732a8f6eb6)
* [HIP] Fix HIP test on windows due to lld suffixAaron En Ye Shi2020-12-012-3/+3
| | | | | | | | | | | On Windows, lld is instead named lld.exe, therefore a few HIP tests are failing. Instead the wildcard should be modified to .*lld.* to handle .exe. This fixes the bug: https://bugs.llvm.org/show_bug.cgi?id=48289. Differential Revision: https://reviews.llvm.org/D92342 (cherry picked from commit f89e9c8201ea5a5b63af854c92ed26bc7ab4b8db)
View Lorry Controller Status