Feature/merge upstream 20210519 #58
Merged
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
Override __cxa_atexit and ignore callbacks. This prevents crashes in a configuration when the symbolizer is built into sanitizer runtime and consequently into the test process. LLVM libraries have some global objects destroyed during exit, so if the test process triggers any bugs after that, the symbolizer crashes. An example stack trace of such crash: For the standalone llvm-symbolizer this does not hurt, we just don't destroy few global objects on exit. Reviewed By: kda Differential Revision: https://reviews.llvm.org/D102470
This patch introduces a new class, MaxVFCandidates, that holds the maximum vectorization factors that have been computed for both scalable and fixed-width vectors. This patch is intended to be NFC for fixed-width vectors, although considering a scalable max VF (which is disabled by default) pessimises tail-loop elimination, since it can no longer determine if any chosen VF (less than fixed/scalable MaxVFs) is guaranteed to handle all vector iterations if the trip-count is known. This issue will be addressed in a future patch. Reviewed By: fhahn, david-arm Differential Revision: https://reviews.llvm.org/D98721
It was printing RegUnits as Regs, leading to much confusion in the debug logs.
A long time ago LLDB wanted to start using StringRef instead of C-Strings/ConstString but was blocked by the fact that the StringRef constructor that takes a C-string was asserting that the C-string isn't a nullptr. To workaround this, D24697 introduced a special function called `withNullAsEmpty` and that's what LLDB (and only LLDB) started to use to build StringRefs from C-strings. A bit later it seems that `withNullAsEmpty` was declared too awkward to use and instead the assert in the StringRef constructor got removed (see D24904). The rest of LLDB was then converted to StringRef by just calling the now perfectly usable implicit constructor. However, all the calls to `withNullAsEmpty` just remained and are now just strange artefacts in the code base that just look out of place. It's also curiously a LLDB-exclusive function and no other project ever called it since it's introduction half a decade ago. This patch removes all uses of `withNullAsEmpty`. The follow up will be to remove the function from StringRef. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D102597
In the case of TypedefDecls we set the DeclContext after we imported it. It turns out, it could lead to null pointer dereferences during the cleanup part of a failed import. This patch demonstrates this issue and fixes it by checking if the DeclContext is available or not. Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D102640
This allows cast/dyn_cast'ing from VPUser to recipes. This is needed because there are VPUsers that are not recipes. Reviewed By: gilr, a.elovikov Differential Revision: https://reviews.llvm.org/D100257
Where the RVV specification writes `vs2, vs1`, our TableGen patterns use `rs1, rs2`. These differences can easily cause confusion. The VMANDNOT instruction performs `LHS && !RHS`, and similarly for VMORNOT. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D102606
Note that the FunctionCallee members aren't pointer, so the nullptr was just an alternative way to call the default constructor.
Passing template parameter packs to std::map doesn't work in VS 2017/2019, so this updates the preprocessor version check to use an alternate version in VS2019, as well. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D102260
Now that complex constants are supported, we can also fold. Differential Revision: https://reviews.llvm.org/D102616
This patch stops lit from looking on the PATH for clang, lld and other users of use_llvm_tool (currently only the debuginfo-tests) unless the call explicitly requests to opt into using the PATH. When not opting in, tests will only look in the build directory. See the mailing list thread starting from https://lists.llvm.org/pipermail/llvm-dev/2021-May/150421.html. See the review for details of why decisions were made about when still to use the PATH. Reviewed by: thopre Differential Revision: https://reviews.llvm.org/D102630
This allows tests to detect whether to run or not, dependent on which LLD version is required for the test. Reviewed by: thopre Differential Revision: https://reviews.llvm.org/D101997
This fixes the initialization of objects in the __constant address space that occurs when declaring the object. Fixes part of PR42566 Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D102248
Differential Revision: https://reviews.llvm.org/D100396
Keep the manual GFX10DEFWAVE checks for VGPRBlocks
…e wave32.ll tests" This is failing on buildbots but not locally - not sure why
We have checks for these but no actual RUNs were using them
Ensure these are all zero
…Driver
That way, it's done only once instead of every time shouldExportSymbol() is
called.
Possibly a bit faster:
% ministat at_main at_symtodo
x at_main
+ at_symtodo
N Min Max Median Avg Stddev
x 30 3.9732189 4.114846 4.024621 4.0304692 0.037022865
+ 30 3.93766 4.0510042 3.9973931 3.991469 0.028472565
Difference at 95.0% confidence
-0.0390002 +/- 0.0170714
-0.967635% +/- 0.423559%
(Student's t, pooled s = 0.0330256)
In other runs with n=30 it makes no perf difference, so maybe it's just noise.
But being able to quickly and conveniently answer "is this symbol exported?"
is useful for fixing PR50373 and for implementing -dead_strip, so this seems
like a good change regardless.
No behavior change.
Differential Revision: https://reviews.llvm.org/D102661
Noticed while investigating PR50364, the truncation costs for v4i64->v4i16/v4i8 and v8i32->v8i8 were way too optimistic for a shuffle sequence that usually matches the AVX1 codegen (they matched AVX512 numbers which have actual truncation instructions!).
The problem with debug mode tests is that it isn't known which particular _LIBCPP_ASSERT causes the test to exit, and as shown by https://reviews.llvm.org/D100029 and 2908eb2 it might be not the expected one. The patch adds TEST_LIBCPP_ASSERT_FAILURE macro that allows checking _LIBCPP_ASSERT message to ensure we caught an expected failure. Reviewed By: Quuxplusone, ldionne Differential Revision: https://reviews.llvm.org/D100595
…dratic IndVars runtime) While i would like to keep the right value here, i would also like to be able to actually compile e.g. vanilla test-suite. 256 is a pretty random guess, it should be pretty good enough for serious loops, but small enough to result in tolerant compile times for certain edge cases. https://bugs.llvm.org/show_bug.cgi?id=50384
This required some changes to, instead of eagerly making PHI's in the UnwindDest valid as-if the BB is already not a predecessor, to be valid while BB is still a predecessor.
The checks (both positive and negative checks) in the test case hip-include-path.hip could mistakenly end up matching the string "clang" from the InstalledDir in case the build dir for example was named "/home/username/build-clang/". Intention with this patch is to tighten up the checks a bit to filter our the part of the paths that match with InstalledDir when doing the checks, as well as matching "/lib/clang/" rather than just "clang/". Problem was found when building with -DCLANG_DEFAULT_RTLIB=compiler-rt -DCLANG_DEFAULT_CXX_STDLIB=libc++ and having "clang/" in the path to the build dir. Reviewed By: yaxunl Differential Revision: https://reviews.llvm.org/D102723
Remnants from when the Atom model was copied from the Btver2 model.....
We might encounter an undeduced type before calling getTypeAlignInChars. NOTE: this retrieves the fix from 8f80c66, which was removed in Adam's followup fix fbfcfdb. We originally thought the crash was caused by recovery-ast, but it turns out it can occur for other cases, e.g. typo-correction. Differential Revision: https://reviews.llvm.org/D102750
This reapplies commit 95033eb3 that reverted commit 1d9e8e1. The tests were failing on Windows due to spaces and backslashes in paths not being handled carefully.
This is a step towards relying more on node-level FMF rather than function-wide or target settings. I think it was just an oversight that we didn't get this path in D87361 or follow-on patches. The lack of FMF propagation is blocking D90901 from converting tests to IR-level FMF. We can't do much more than this currently because we also fail to propagate flags from x86-specific node to generic FMA node. That would be another patch, so the test just verifies that we can transfer from IR to initial SDAG node. Differential Revision: https://reviews.llvm.org/D102725
Differential Revision: https://reviews.llvm.org/D102256
…omInst In InnerLoopVectorizer::setDebugLocFromInst we were previously asserting that the VF is not scalable. This is because we want to use the number of elements to create a duplication factor for the debug profiling data. However, for scalable vectors we only know the minimum number of elements. I've simply removed the assert for now and added a FIXME saying that we assume vscale is always 1. When vscale is not 1 it just means that the profiling data isn't as accurate, but shouldn't cause any functional problems.
… case only" This reverts commit ca23a38. Revert due to EXPENSIVE_CHECKS fail.
Drop the vector dialect EDSC subdirectory and update all uses.
Intriniscs reading or writing the FFR register need to model the fact there is additional state being read/wrtten. Model this state as inaccessible memory. * setffr => write inaccessiblememonly * rdffr => read inaccessiblememonly * ldff* => read arg memory, write inaccessiblemem * ldnf => read arg memory, write inaccessiblemem
… known" This reverts commit 892497c. Breaks tests, see comments on https://reviews.llvm.org/D102542
`bool` is considered to be unsigned according to `std::is_unsigned<bool>::value` (and `Type::GetTypeInfo`). Encoding it as signed int works fine for normal variables and fields, but breaks when reading the values of boolean bitfields. If the field is declared as `bool b : 1` and has a value of `0b1`, the call to `SBValue::GetValueAsSigned()` will return `-1`. Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D102685
The patch extends the yaml code generation to support the following new OpDSL constructs: - captures - constants - iteration index accesses - predefined types These changes have been introduced by revision https://reviews.llvm.org/D101364. Differential Revision: https://reviews.llvm.org/D102075
Match whats documented in the Intel AOM (and Agner/instlatx64 agree) - these are all Port0 only. Now that we can use in-order models in llvm-mca, the atom model is a good "worst case scenario" analysis for x86.
…ller indices vector as well Generalize the fix from rGd0902a8665b1 by ensuring we widen/narrow the indices subvector first and then perform the ZERO_EXTEND_VECTOR_INREG (if necessary), which should allow us to perform the variable permutes with source/destination/indices vectors of any widths.
…_rnglists_base (used by GCC) Refactor code only for D98289. Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D99653
…sts_base (used by GCC)
DW_AT_ranges can use DW_FORM_sec_offset (instead of DW_FORM_rnglistx).
In such case DW_AT_rnglists_base does not need to be present.
DWARF-5 spec:
"If the offset_entry_count is zero, then DW_FORM_rnglistx cannot
be used to access a range list; DW_FORM_sec_offset must be used
instead. If the offset_entry_count is non-zero, then
DW_FORM_rnglistx may be used to access a range list;"
This fix is for TestTypeCompletion.py category `dwarf` using GCC with DWARF-5.
The fix just provides GetRnglist() lazy getter for `m_rnglist_table`.
The testcase is easier to review by:
diff -u lldb/test/Shell/SymbolFile/DWARF/DW_AT_low_pc-addrx.s \
lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s
Differential Revision: https://reviews.llvm.org/D98289
…ransform the sequence LEA/SUB to SUB/SUB" Reports on D101970 indicate this is causing failures on multi-stage compiles.
…e case only" The current implementation assumes the destination type of shuffle is the same as the decomposed ones. Add the check to avoid crush when the condition is not satisfied. This fixes PR37616. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D102751
…en integer arguments to int64 in unprototyped function calls Reviewed By: Aaron Ballman Differential Revision: https://reviews.llvm.org/D101640
The test works correctly on Windows, the linked bug has been resolved. Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D102769
…ser - Part 1 - This patch (is one in a series of patches) which introduces HLASM Parser support (for the first parameter of inline asm statements) to LLVM ([[ https://lists.llvm.org/pipermail/llvm-dev/2021-January/147686.html | main RFC here ]]) - This patch in particular introduces HLASM Parser support for Z machine instructions. - The approach taken here was to subclass `AsmParser`, and make various functions and variables as "protected" wherever appropriate. - The `HLASMAsmParser` class overrides the `parseStatement` function. Two new private functions `parseAsHLASMLabel` and `parseAsMachineInstruction` are introduced as well. The general syntax is laid out as follows (more information available in [[ https://www.ibm.com/support/knowledgecenter/SSENW6_1.6.0/com.ibm.hlasm.v1r6.asm/asmr1023.pdf | HLASM V1R6 Language Reference Manual ]] - Chapter 2 - Instruction Statement Format): ``` <TokA><spaces.*><TokB><spaces.*><TokC><spaces.*><TokD> ``` 1. TokA is referred to as the Name Entry. This token is optional 2. TokB is referred to as the Operation Entry. This token is mandatory. 3. TokC is referred to as the Operand Entry. This token is mandatory 4. TokD is referred to as the Remarks Entry. This token is optional - If TokA is provided, then we either parse TokA as a possible comment or as a label (Name Entry), Tok B as the Operation Entry and so on. - If TokA is not provided (i.e. we have one or more spaces and then the first token), then we will parse the first token (i.e TokB) as a possible Z machine instruction, TokC as the operands to the Z machine instruction and TokD as a possible Remark field - TokC (Operand Entry), no spaces are allowed between OperandEntries. If a space occurs it is classified as an error. - TokD if provided is taken as is, and emitted as a comment. The following additional approach was examined, but not taken: - Adding custom private only functions to base AsmParser class, and only invoking them for z/OS. While this would eliminate the need for another child class, these private functions would be of non-use to every other target. Similarly, adding any pure virtual functions to the base MCAsmParser class and overriding them in AsmParser would also have the same disadvantage. Testing: - This patch doesn't have tests added with it, for the sole reason that MCStreamer Support and Object File support hasn't been added for the z/OS target (yet). Hence, it's not possible generate code outright for the z/OS target. They are in the process of being committed / process of being worked on. - Any comments / feedback on how to combat this "lack of testing" due to other missing required features is appreciated. Reviewed By: Kai, uweigand Differential Revision: https://reviews.llvm.org/D98276
…merge-upstream-20210519
Update regression tests following 1c7f323. Need to specify signext/zeroext at call.
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/19.
Pass regression tests.