Feature/merge upstream 20210504 #53
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
Fix assertion in SVals.h apparently caused by https://reviews.llvm.org/D89055. clang:clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:596: clang::ento::loc::MemRegionVal::MemRegionVal(const clang::ento::MemRegion *): Assertion `r' failed. Backtrace: ... clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h:597:3 clang::QualType, clang::QualType) clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:773:18 clang::QualType, clang::QualType) clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:612:12 clang::QualType) clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:587:12 namespace)::RegionBindingsRef const&, clang::ento::Loc, clang::QualType) clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1510:24 ... Reviewed By: ASDenysPetrov Differential Revision: https://reviews.llvm.org/D101635
…mponents
When producing the runtime type information for a component of a derived type
that had a LEN type parameter, we were not allowing a KIND parameter of the
derived type. This was causing one of the NAG correctness tests to fail
(.../hibiya/d5.f90).
I added a test to our own test suite to check for this.
Also, I fixed a typo in .../module/__fortran_type_info.f90.
I allowed KIND type parameters to be used for the declarations of components
that use LEN parameters by constant folding the value of the LEN parameter. To
make the constant folding work, I had to put the semantics::DerivedTypeSpec of
the associated derived type into the folding context. To get this
semantics::DerivedTypeSpec, I changed the value of the semantics::Scope object
that was passed to DescribeComponent() to be the derived type scope rather than
the containing non-derived type scope.
This scope change, in turn, caused differences in the symbol table output that
is checked in typeinfo01.f90. Most of these differences were in the order that
the symbols appeared in the dump. But one of them changed one of the values
from "CHARACTER(2_8,1)" to "CHARACTER(1_8,1)". I'm not sure if these changes
are significant. Please verify that the results of this test are still valid.
Also, I wonder if there are other situations in this code where we should be
folding constants. For example, what if the field of a component has a
component whose type is a PDT with a LEN type parameter, and the component's
declaration depends on the KIND type parameter of the current PDT. Here's an
example:
type string(stringkind)
integer,kind :: stringkind
character(stringkind) :: value
end type string
type outer(kindparam)
integer,kind :: kindparam
type(string(kindparam)) :: field
end type outer
I don't understand the code or what it's trying to accomplish well enough to
figure out if such cases are correctly handled by my new code.
Differential Revision: https://reviews.llvm.org/D101482
Document relevant gcc versions and dates. Differential Revision: https://reviews.llvm.org/D101530
This patch merges STR<S,D,Q,W,X>pre-STR<S,D,Q,W,X>ui and LDR<S,D,Q,W,X>pre-LDR<S,D,Q,W,X>ui instruction pairs into a single STP<S,D,Q,W,X>pre and LDP<S,D,Q,W,X>pre instruction, respectively. For each pair, there is a MIR test that verifies this optimization. Differential Revision: https://reviews.llvm.org/D99272 Change-Id: Ie97a20c8c716c08492fe229c22e14e3c98ef08b7
…fled. If the extracts from the non-power-2 vectors are recognized as shuffles, need some extra checks to not crash cost calculations if trying to gext the ecost for subvector extracts. In this case need to check carefully that we do not exit out of bounds of the original vector, otherwise the TTI's cost model will crash on assert. Differential Revision: https://reviews.llvm.org/D101477
* `std::ranges::begin`
* `std::ranges::cbegin`
* `std::ranges::end`
* `std::ranges::cend`
* `std::ranges::iterator` (required for `end`)
Implements parts of:
* P0896R4 The One Ranges Proposal`
Co-author: @zoecarver
Depends on D90999, D100160.
Differential Revision: https://reviews.llvm.org/D100255
…nge aliases
* `std::ranges::range`
* `std::ranges::sentinel_t`
* `std::ranges::range_difference_t`
* `std::ranges::range_value_t`
* `std::ranges::range_reference_t`
* `std::ranges::range_rvalue_reference_t`
* `std::ranges::common_range`
`range_size_t` depends on `sized_range` and will be added alongside it.
Implements parts of:
* P0896R4 The One Ranges Proposal`
Depends on D100255.
Differential Revision: https://reviews.llvm.org/D100269
Introduce an extra scope (another static function) to replace calls to `unique_ptr::reset` with implicit destructors via RAII. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101542
Move some types in STLExtras.h which are named and behave identically to STL types from future standards into a dedicated header. This keeps them organized (they are not "extras" in the same sense as most types in STLExtras.h are) and fixes circular dependencies in future patches. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D100668
If available, use the clang that is already built in the same project as CUDA compiler unless another executable is explicitly defined. This also ensures the generated deviceRTL IR will be consistent with the version of Clang. This patch is required to reliably test OpenMP offloading in a buildbot without either a two-stage build (e.g. with LLVM_ENABLE_RUNTIMES) or a separately installed clang on the worker that will eventually become outdated. Reviewed By: tianshilei1992 Differential Revision: https://reviews.llvm.org/D101265
These operations don't exist natively, so just let the target-independent code expand to plain shifts. The generated sequences could probably be optimized a bit more, but they seem good enough for now. Differential Revision: https://reviews.llvm.org/D101574
…r.reduction Three patterns are added to convert into vector.multi_reduction into a sequence of vector.reduction as the following: - Transpose the inputs so inner most dimensions are always reduction. - Reduce rank of vector.multi_reduction into 2d with inner most reduction dim (get the 2d canical form) - 2D canonical form is converted into a sequence of vector.reduction. There are two things we might worth in a follow up diff: - An scf.for (maybe optionally) around vector.reduction instead of unrolling it. - Breakdown the vector.reduction into a sequence of vector.reduction (e.g tree-based reduction) instead of relying on how downstream dialects handle it. Note: this will requires passing target-vector-length Differential Revision: https://reviews.llvm.org/D101570
Stop using the compatibility spellings of `OF_{None,Text,Append}`
left behind by 1f67a3c. A follow-up
will remove them.
Differential Revision: https://reviews.llvm.org/D101650
…t in the service queue This reverts commit 6712534. Differential Revision: https://reviews.llvm.org/D101437
Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D100669
Fixes the following warnings observerd when building the experimental
m68k backend (-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="M68k"):
../lib/Target/M68k/M68kMachineFunction.h:71:3: warning: explicitly
defaulted default constructor is implicitly deleted
[-Wdefaulted-function-deleted]
M68kMachineFunctionInfo() = default;
^
../lib/Target/M68k/M68kMachineFunction.h:24:20: note: default
constructor of 'M68kMachineFunctionInfo' is implicitly deleted because
field 'MF' of reference type 'llvm::MachineFunction &' would not be
initialized
MachineFunction &MF;
^
In file included from ../lib/Target/M68k/M68kISelLowering.cpp:18:
In file included from ../lib/Target/M68k/M68kSubtarget.h:17:
../lib/Target/M68k/M68kFrameLowering.h:60:8: warning:
'llvm::M68kFrameLowering::emitCalleeSavedFrameMoves' hides overloaded
virtual functions [-Woverloaded-virtual]
void emitCalleeSavedFrameMoves(MachineBasicBlock &MBB,
^
../include/llvm/CodeGen/TargetFrameLowering.h:215:3: note: hidden
overloaded virtual function
'llvm::TargetFrameLowering::emitCalleeSavedFrameMoves' declared here:
different number of parameters (2 vs 3)
emitCalleeSavedFrameMoves(MachineBasicBlock &MBB,
^
../include/llvm/CodeGen/TargetFrameLowering.h:218:16: note: hidden
overloaded virtual function
'llvm::TargetFrameLowering::emitCalleeSavedFrameMoves' declared here:
different number of parameters (4 vs 3)
virtual void emitCalleeSavedFrameMoves(MachineBasicBlock &MBB,
^
pr/50071
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D101588
Used by the Linux kernel's CONFIG_X86_DECODER_SELFTEST. Link: ClangBuiltLinux/linux#1130 Reviewed By: MaskRay, jhenderson, rupprecht Differential Revision: https://reviews.llvm.org/D101483
Without this, CMake deduplicates the /I flag breaking the build. See https://cmake.org/cmake/help/v3.13/command/target_compile_options.html for more details on why this is needed. Differential Revision: https://reviews.llvm.org/D101550
…aying" This reverts commit c9c4676. Reason for revert: note-amd-valid-v3.s test fails if AMDGPU is not built.
…cript. This re-reverts one piece of 1b88557, reapplying one piece of D101437 (but not the "service"-queue piece of it). It turns out that the behavior of `grep [^ -~]`, or even `grep [A-Z]`, depends on locale, specifically `LC_COLLATE`. So we want to make sure we're not in any weird locale, no matter what machine we're running on. Yes, "en_US.UTF-8" counts as weird! https://stackoverflow.com/questions/67320156/misbehavior-of-gnu-grep-when-grepping-for-ignores-spaces https://stackoverflow.com/questions/6799872/how-to-make-grep-a-z-independent-of-locale
Reviewed By: fhahn, hans Differential Revision: https://reviews.llvm.org/D101278
This introduces a flag that aborts if we ever reduce to IR that fails the verifier. Reviewed By: swamulism, arichardson Differential Revision: https://reviews.llvm.org/D101279
As discussed in https://lists.llvm.org/pipermail/llvm-dev/2021-April/150225.html, the current comments for TracksLiveness property and isKill flag are confusing. This patch makes the comments more clearer. Differential Revision: https://reviews.llvm.org/D101500
This patch migrates the TTI cost interfaces to return an InstructionCost. See this patch for the introduction of the type: https://reviews.llvm.org/D91174 See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2020-November/146408.html Reviewed By: sdesmalen, kparzysz Differential Revision: https://reviews.llvm.org/D101533
[libc] Introduce asctime, asctime_r to LLVM libc asctime and asctime_r share the same common code. They call asctime_internal a static inline function. asctime uses snprintf to return the string representation in a buffer. It uses the following format (26 characters is the buffer size) as per 7.27.3.1 section in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf. The buf parameter for asctime_r shall point to a buffer of at least 26 bytes. snprintf(buf, 26, "%.3s %.3s%3d %.2d:%.2d:%.2d %d\n",...) Reviewed By: sivachandra Differential Revision: https://reviews.llvm.org/D99686
Two of these are trivial. The third (shared.s) did have some expectations changes but only due to two data symbols being re-ordered. Differential Revision: https://reviews.llvm.org/D101711
Previously, any change in any function in an SCC would cause all analyses for all functions in the SCC to be invalidated. With this change, we now manually invalidate analyses for functions we modify, then let the pass manager know that all function analyses should be preserved. So far this only touches the inliner, argpromotion, funcattrs, and updateCGAndAnalysisManager(), since they are the most used. Slight compile time improvements: http://llvm-compile-time-tracker.com/compare.php?from=326da4adcb8def2abdd530299d87ce951c0edec9&to=8942c7669f330082ef159f3c6c57c3c28484f4be&stat=instructions Reviewed By: mtrofin Differential Revision: https://reviews.llvm.org/D100917
… add". These two commands add a list of commands to the breakpoint/watchpoint. The current implementation only supports replacing the current command list. I started with that as overwrite seems to be the most common operation. But using "add" will allow us to later offer other add-modes: "prepend", "append" and "insert". That and "overwrite" then make up a useful set of options for this operation.
… conditions
This patch optimizes the remaining possible cases in D101191 by generalizing isImpliedCondition()-based
foldings.
Assume that there is `op a, (select b, _, _)` where op is one of `and i1`, `or i1` or their select forms.
We can do the following optimization based on the result of `isImpliedCondition(a, b)`:
If a = true implies…
- b = true:
- select a, (select b, A, B), false => select a, A, false : https://alive2.llvm.org/ce/z/WCnZYh
- and a, (select b, A, B) => select a, A, false : https://alive2.llvm.org/ce/z/uZhcMG
- b = false:
- select a, (select b, A, B), false => select a, B, false : https://alive2.llvm.org/ce/z/c2hJpV
- and a, (select b, A, B) => select a, B, false : https://alive2.llvm.org/ce/z/5ggwMM
If a = false implies…
- b = true:
- select a, true, (select b, A, B) => select a, true, A : https://alive2.llvm.org/ce/z/tidKvH
- or a, (select b, A, B) => select a, true, A : https://alive2.llvm.org/ce/z/cC-uyb
- b = false:
- select a, true, (select b, A, B) => select a, true, B : https://alive2.llvm.org/ce/z/ZXpJq9
- or a, (select b, A, B) => select a, true, B : https://alive2.llvm.org/ce/z/hnDrJj
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D101720
`shouldImport` was not returning true in PIC mode even though out assumption elsewhere (in Relocations.cpp:scanRelocations) is that we don't report undefined symbols in PIC mode today. This was resulting functions that were undefined and but also not imported which hits an assert later on that all functions have valid indexes. Differential Revision: https://reviews.llvm.org/D101716
…LoopExits of IndVarSimplify Instruction has mayHaveSideEffects method that returns true if mayThrow return true because this is called internally in the first method. As such, the call being removed is redundant. Patch By: vdsered (Daniil Seredkin) Differential Revision: https://reviews.llvm.org/D101685
…hift Lowerings equal and arithmetic_right_shift for elementwise ops to linalg dialect using linalg.generic Reviewed By: rsuderman Differential Revision: https://reviews.llvm.org/D101804
TransferReadOps that are a scalar read + broadcast are handled by TransferReadToVectorLoadLowering. Differential Revision: https://reviews.llvm.org/D101808
…ions The use of llvm::sort causes periodic failures on the bot with EXPENSIVE_CHECKS enabled, as the regular sort pre-shuffles the array in the expensive checks mode, leading to a non-deterministic test result which causes the CodeGenCXX/attr-cpuspecific-outoflinedefs.cpp testcase to fail on the bot (http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/).
Contributors often confused by whether this is a server or local issue.
ld64 automatically renames many sections depending on output type and assorted flags. Here, we implement the most common configs. We can add more obscure flags and behaviors as needed. Depends on D101393 Differential Revision: https://reviews.llvm.org/D101395
This patch adds initial unit tests for appendToUsedList in the ModuleUtils. It specifically tests changes from https://reviews.llvm.org/D101363 which intent to allow insertion of globals in non-zero address spaces into the llvm used lists. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D101746
As pointed out in D101726, this function already exists in MathExtras. It uses different types, but with the values used here I believe that should not make a functional difference.
This patch adds support for splatting i1 types to fixed-length or scalable vector types. It does so by lowering the operation to a SETCC of the equivalent i8 type. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D101465
Warn when a declaration uses an identifier that doesn't obey the reserved identifier rule from C and/or C++. Differential Revision: https://reviews.llvm.org/D93095
Differential Revision: https://reviews.llvm.org/D101743
…merge-upstream-20210504
VPLeagalization stuff is reverted by 02c5ba8. So, comment out a VE specific function using VPLegalization to avoid compile errors.
|
Pass regression tests. |
Closed
kaz7
pushed a commit
that referenced
this pull request
May 22, 2023
…callback
The `TypeSystemMap::m_mutex` guards against concurrent modifications
of members of `TypeSystemMap`. In particular, `m_map`.
`TypeSystemMap::ForEach` iterates through the entire `m_map` calling
a user-specified callback for each entry. This is all done while
`m_mutex` is locked. However, there's nothing that guarantees that
the callback itself won't call back into `TypeSystemMap` APIs on the
same thread. This lead to double-locking `m_mutex`, which is undefined
behaviour. We've seen this cause a deadlock in the swift plugin with
following backtrace:
```
int main() {
std::unique_ptr<int> up = std::make_unique<int>(5);
volatile int val = *up;
return val;
}
clang++ -std=c++2a -g -O1 main.cpp
./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b
```
```
frame #4: std::lock_guard<std::mutex>::lock_guard
frame #5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock #2
frame #6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage
frame #7: lldb_private::Target::GetScratchTypeSystemForLanguage
...
frame #26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths
frame #27: lldb_private::SwiftASTContext::LoadModule
frame #30: swift::ModuleDecl::collectLinkLibraries
frame #31: lldb_private::SwiftASTContext::LoadModule
frame #34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl
frame #35: lldb_private::SwiftASTContext::PerformCompileUnitImports
frame #36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext
frame #37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState
frame #38: lldb_private::Target::GetPersistentSymbol
frame #41: lldb_private::TypeSystemMap::ForEach <<<< Lock #1
frame #42: lldb_private::Target::GetPersistentSymbol
frame #43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols
frame #44: lldb_private::IRExecutionUnit::FindSymbol
frame #45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence
frame #46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame #47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol
frame #48: llvm::LinkingSymbolResolver::findSymbol
frame #49: llvm::LegacyJITSymbolResolver::lookup
frame #50: llvm::RuntimeDyldImpl::resolveExternalSymbols
frame #51: llvm::RuntimeDyldImpl::resolveRelocations
frame #52: llvm::MCJIT::finalizeLoadedModules
frame #53: llvm::MCJIT::finalizeObject
frame #54: lldb_private::IRExecutionUnit::ReportAllocations
frame #55: lldb_private::IRExecutionUnit::GetRunnableInfo
frame #56: lldb_private::ClangExpressionParser::PrepareForExecution
frame #57: lldb_private::ClangUserExpression::TryParse
frame #58: lldb_private::ClangUserExpression::Parse
```
Our solution is to simply iterate over a local copy of `m_map`.
**Testing**
* Confirmed on manual reproducer (would reproduce 100% of the time
before the patch)
Differential Revision: https://reviews.llvm.org/D149949
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 up to 2021/5/4, f800ac8.
I'll post the result of regression test later.