-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/merge upstream 20210817 2 #81
Merged
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
On Windows, the documentation states that when using sscanf_s, each %c and %s specifier must also have additional size parameter. This patch adds the size parameter in the one place where %c is used. Differential Revision: https://reviews.llvm.org/D105931
* Add comment to help ensure new construct data are added in two places * Check for division by zero in the loop worksharing code * Check for syntax errors in parrange parsing Differential Revision: https://reviews.llvm.org/D105929
… concat_vectors(x,y,a,b) Follow-up to D107068, attempt to fold nested concat_vectors/undefs, as long as both the vector and inner subvector types are legal. This exposed the same issue in ARM's MVE LowerCONCAT_VECTORS_i1 (raised as PR51365) and AArch64's performConcatVectorsCombine which both assumed concat_vectors only took 2 subvector operands. Differential Revision: https://reviews.llvm.org/D107597
When assertions are turned off, the `llvm::Error` value created at the start of this function is overwritten using the move-assignment operator, but the success value is never checked. Whenever a TypeSystem cannot be found or created, this can lead to lldb core dumping with: Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Fix this by not creating a `llvm::Error` value in advance, and directly returning the result of `llvm::make_error` instead, whenever an error is encountered. See also: <https://bugs.freebsd.org/253881> and <https://bugs.freebsd.org/257829>. Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D108088
This is done for consistency, since that's what we do everywhere else in the library.
SwitchInst should have a void result type. Add a check to the verifier to catch this error. Reviewed By: samparker Differential Revision: https://reviews.llvm.org/D108084
Regression tests for D108088 . Reviewed By: mib Differential Revision: https://reviews.llvm.org/D108121
At least when compiling with gcc, this is not supported and will result in errors when linking against the profiler runtime. Only use the pragma comment linker based code with MSVC, but not with a mingw toolchain. This also undoes D107620, which shouldn't be relevant anymore. Differential Revision: https://reviews.llvm.org/D108095
Test coverage for D108058
s/senstive/senstive/g
`scudo::uptr` was defined as an `unsigned long` on 32-b platform, while a `uintptr_t` is usually defined as an `unsigned int`. This worked, this was not consistent, particularly with regard to format string specifiers. As suggested by Vitaly, since we are including `stdint.h`, define the internal `scudo` integer types to those. Differential Revision: https://reviews.llvm.org/D108089
…ember from the ASTContext class. It is completely unused and not needed to be kept, so let us remove it. Differential Revision: https://reviews.llvm.org/D107719
This reverts commit b7425e9.
This reverts commit 5fc841d.
Two standalone LoopRotate passes scheduled using createFunctionToLoopPassAdaptor() currently enable MemorySSA. However, while LoopRotate can preserve MemorySSA, it does not use it, so requiring MemorySSA is unnecessary. This change doesn't have a practical compile-time impact by itself, because subsequent passes still request MemorySSA. Differential Revision: https://reviews.llvm.org/D108073
LoopLoadElimination, LoopVersioning and LoopVectorize currently fetch MemorySSA when construction LoopAccessAnalysis. However, LoopAccessAnalysis does not actually use MemorySSA and we can pass nullptr instead. This saves one MemorySSA calculation in the default pipeline, and thus improves compile-time. Differential Revision: https://reviews.llvm.org/D108074
Reviewed By: bixia Differential Revision: https://reviews.llvm.org/D108055
These operations are not lowered to from any source dialect and are only used for redundant tests. Removing these named ops, along with their associated tests, will make migration to YAML operations much more convenient. Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D107993
This option has been enabled by default for quite a while now. The practical impact of removing the option is that MSSA use cannot be disabled in default pipelines (both LPM and NPM) and in manual LPM invocations. NPM can still choose to enable/disable MSSA using loop vs loop-mssa. The next step will be to require MSSA for LICM and drop the AST-based implementation entirely. Differential Revision: https://reviews.llvm.org/D108075
Check if a remateralizable nstruction does not have any virtual register uses. Even though rematerializable RA might not actually rematerialize it in this scenario. In that case we do not want to hoist such instruction out of the loop in a believe RA will sink it back if needed. This already has impact on AMDGPU target which does not check for this condition in its isTriviallyReMaterializable implementation and have instructions with virtual register uses enabled. The other targets are not impacted at this point although will be when D106408 lands. Differential Revision: https://reviews.llvm.org/D107677
The commit b7425e9: [NFC] fix typos is harmless but was reverted by accident. Reapply.
Update LLVM configuration to define `HAVE_UNW_ADD_DYNAMIC_FDE` for macOS since llvm/llvm-project@957334382c moved that to a define. Differential Revision: https://reviews.llvm.org/D108157
This patch adds static keyword to internal functions that write binary id to restrict visibility to the file that they are declared. Differential Revision: https://reviews.llvm.org/D108154
There was an instance of a third-party archive containing multiple _llvm symbols from different files that clashed with each other producing duplicate symbols. Symbols under the LLVM segment don't seem to be producing any meaningful value, so just ignore them. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D108016
Currently isReallyTriviallyReMaterializableGeneric() implementation prevents rematerialization on any virtual register use on the grounds that is not a trivial rematerialization and that we do not want to extend liveranges. It appears that LRE logic does not attempt to extend a liverange of a source register for rematerialization so that is not an issue. That is checked in the LiveRangeEdit::allUsesAvailableAt(). The only non-trivial aspect of it is accounting for tied-defs which normally represent a read-modify-write operation and not rematerializable. The test for a tied-def situation already exists in the /CodeGen/AMDGPU/remat-vop.mir, test_no_remat_v_cvt_f32_i32_sdwa_dst_unused_preserve. The change has affected ARM/Thumb, Mips, RISCV, and x86. For the targets where I more or less understand the asm it seems to reduce spilling (as expected) or be neutral. However, it needs a review by all targets' specialists. Differential Revision: https://reviews.llvm.org/D106408
The patch adds ELF notes into SHT_NOTE sections of ELF offload images passed to clang-offload-wrapper. The new notes use a null-terminated "LLVMOMPOFFLOAD" note name. There are currently three types of notes: VERSION: a string (not null-terminated) representing the ELF offload image structure. The current version '1.0' does not put any restrictions on the structure of the image. If we ever need to come up with a common structure for ELF offload images (e.g. to be able to analyze the images in libomptarget in some standard way), then we will introduce new versions. PRODUCER: a vendor specific name of the producing toolchain. Upstream LLVM uses "LLVM" (not null-terminated). PRODUCER_VERSION: a vendor specific version of the producing toolchain. Upstream LLVM uses LLVM_VERSION_STRING with optional <space> LLVM_REVISION. All three notes are not mandatory currently. Differential Revision: https://reviews.llvm.org/D99551
If both operands are negated, we can invert the min/max and do the negation after: smax (neg nsw X), (neg nsw Y) --> neg nsw (smin X, Y) smin (neg nsw X), (neg nsw Y) --> neg nsw (smax X, Y) This is visible as a remaining regression in D98152. I don't see a way to generalize this for 'unsigned' or adapt Negator to handle it. This only appears to be safe with 'nsw': https://alive2.llvm.org/ce/z/GUy1zJ Differential Revision: https://reviews.llvm.org/D108165
As a part of D107642, this adds pseudo instructions for MQQPR and MQQQQPR register classes, that can spill and reloads entire registers whilst keeping them combined, not splitting them into multiple D subregs that a VLDMIA/VSTMIA would use. This can help certain analyses, and helps to prevent verifier issues with subreg liveness.
This enables subreg liveness in the arm backend when MVE is present, which allows the register allocator to detect when subregister are alive/dead, compared to only acting on full registers. This can helps produce better code on MVE with the way MQPR registers are made up of SPR registers, but is especially helpful for MQQPR and MQQQQPR registers, where there are very few "registers" available and being able to split them up into subregs can help produce much better code. Differential Revision: https://reviews.llvm.org/D107642
Adjust the names of helper function objects to represent better what they do, as suggested in the review of D107098.
…bute Removed AArch64 usage of the getMaxVScale interface, replacing it with the vscale_range(min, max) IR Attribute. Reviewed By: paulwalker-arm Differential Revision: https://reviews.llvm.org/D106277
AIX may use cat_64 for 64 bit cat, this is just update the lit test to accept the name as well. Reviewed By: #powerpc, shchenz Differential Revision: https://reviews.llvm.org/D108149
The corresponding definition was removed on Nov 29, 2016 in commit 5a0a2e6.
Fixes issue: https://bugs.llvm.org/show_bug.cgi?id=47983 The AsmLexer currently has an issue with lexing line comments in files with CRLF line endings, in which it reads the carriage return as being part of the line comment. This causes an error for certain valid comment layouts; this patch fixes this by excluding the carriage return from the line comment. Differential Revision: https://reviews.llvm.org/D90234
Some compilers started complaining about the test: tsan_trace_test.cpp:128:21: error: missing field 'type' initializer Fix it by initializing all 5 fields, even though the type field will be reset in the for loop. Differential Revision: https://reviews.llvm.org/D108207
…omments Fixes an issue with revision 5c6f748. Move the test added in the above commit into the X86 folder, ensuring that it is only run on targets where its triple is valid.
…ace_deref As explained in http://eel.is/c++draft/range.nonprop.cache#note-1, we should allow copy and move elision to happen when calling emplace_deref in non-propagating-cache. Before this change, the only way to emplace into the non-propagating-cache was to call `__set(*it)`, which materialized `*it` when binding it to the reference argument of `__set` and disabled move elision. As a fly-by change, this also renames `__set` to `__emplace` for consistency and adds tests for it. Differential Revision: https://reviews.llvm.org/D107932
Enable `-Wformat` again, and fix the offending instances. Differential Revision: https://reviews.llvm.org/D108168
The loop had no side-effect since first committed in 642594a. While it is obvious what was intended, the code seems to never trigger.
…ast+blend (PR50971) Broadcast is not worse than extract+insert of subvector. https://godbolt.org/z/aPq98G6Yh Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D105390
…DynsymVersions The utility can be reused by llvm-objdump -T. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D108096
Reviewed By: gysit Differential Revision: https://reviews.llvm.org/D108182
Similar to D94907 (llvm-nm -D). The output will match GNU objdump 2.37. Older versions don't use ` (version)` for undefined symbols. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D108097
Summary: Change and replace some functions which IE does not support. This patch is made as a continuation of D92928 revision. Also improve hot keys behavior. Differential Revision: https://reviews.llvm.org/D107366
his is a fix for PR43678, and is an alternate patch to D105723. The basic issue we're running into is that LSR + SCEVExpander are moving the very instruction whose operand we're in the process of expanding. This breaks the subtle and ill-documented invariant which let LSR work. (Full story can be found here: https://reviews.llvm.org/D105723#2878473) Rather than attempting a fix, this change just removes the optimization entirely. The code is entirely untested, and removing it appears to have no impact I can find. This code was added back in 2014 by 1e12f85 with a single test which does not seem to actually test the hoisting logic. From a philosophical standpoint, it also seems very strange to have the expander implementing optimizations which should live in a dedicated transform pass. Differential Revision: https://reviews.llvm.org/D106178
This patch adds an extra option to print the module after running one of the OpenMPOpt passes if debugging is enabled. This makes it much easier to inspect the effects of this pass when doing debugging. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D108146
The current x86_64 implementations do not build on the windows bot machine. We will enable them back after fixing the problem.
…merge-upstream-20210817-2
kaz7
pushed a commit
that referenced
this pull request
Sep 25, 2023
…… (#67069) We noticed some performance issue while in lldb-vscode for grabing the name of the SBValue. Profiling shows SBValue::GetName() can cause synthetic children provider of shared/unique_ptr to deference underlying object and complete it type. This patch lazily moves the dereference from synthetic child provider's Update() method to GetChildAtIndex() so that SBValue::GetName() won't trigger the slow code path. Here is the culprit slow code path: ``` ... frame #59: 0x00007ff4102e0660 liblldb.so.15`SymbolFileDWARF::CompleteType(this=<unavailable>, compiler_type=0x00007ffdd9829450) at SymbolFileDWARF.cpp:1567:25 [opt] ... frame #67: 0x00007ff40fdf9bd4 liblldb.so.15`lldb_private::ValueObject::Dereference(this=0x0000022bb5dfe980, error=0x00007ffdd9829970) at ValueObject.cpp:2672:41 [opt] frame #68: 0x00007ff41011bb0a liblldb.so.15`(anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::Update(this=0x000002298fb94380) at LibStdcpp.cpp:403:40 [opt] frame #69: 0x00007ff41011af9a liblldb.so.15`lldb_private::formatters::LibStdcppSharedPtrSyntheticFrontEndCreator(lldb_private::CXXSyntheticChildren*, std::shared_ptr<lldb_private::ValueObject>) [inlined] (anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::LibStdcppSharedPtrSyntheticFrontEnd(this=0x000002298fb94380, valobj_sp=<unavailable>) at LibStdcpp.cpp:371:5 [opt] ... frame #78: 0x00007ff40fdf6e42 liblldb.so.15`lldb_private::ValueObject::CalculateSyntheticValue(this=0x000002296c66a500) at ValueObject.cpp:1836:27 [opt] frame #79: 0x00007ff40fdf1939 liblldb.so.15`lldb_private::ValueObject::GetSyntheticValue(this=<unavailable>) at ValueObject.cpp:1867:3 [opt] frame #80: 0x00007ff40fc89008 liblldb.so.15`ValueImpl::GetSP(this=0x0000022c71b90de0, stop_locker=0x00007ffdd9829d00, lock=0x00007ffdd9829d08, error=0x00007ffdd9829d18) at SBValue.cpp:141:46 [opt] frame #81: 0x00007ff40fc7d82a liblldb.so.15`lldb::SBValue::GetSP(ValueLocker&) const [inlined] ValueLocker::GetLockedSP(this=0x00007ffdd9829d00, in_value=<unavailable>) at SBValue.cpp:208:21 [opt] frame #82: 0x00007ff40fc7d817 liblldb.so.15`lldb::SBValue::GetSP(this=0x00007ffdd9829d90, locker=0x00007ffdd9829d00) const at SBValue.cpp:1047:17 [opt] frame #83: 0x00007ff40fc7da6f liblldb.so.15`lldb::SBValue::GetName(this=0x00007ffdd9829d90) at SBValue.cpp:294:32 [opt] ... ``` Differential Revision: https://reviews.llvm.org/D159542
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.
Merge upstream/main up to 2021/8/17.
Pass regression tests.