[pull] main from MaxMood96:main #26
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Differential Revision: https://reviews.llvm.org/D108682
PowerPC can model these instructions, so we don't need this flag set. Reviewed By: shchenz, jsji Differential Revision: https://reviews.llvm.org/D71983
…_create. Also, added a call to munmap on error in thrd_create.
SymbolRefAttr is fundamentally a base string plus a sequence of nested references. Instead of storing the string data as a copies StringRef, store it as an already-uniqued StringAttr. This makes a lot of things simpler and more efficient because: 1) references to the symbol are already stored as StringAttr's: there is no need to copy the string data into MLIRContext multiple times. 2) This allows pointer comparisons instead of string comparisons (or redundant uniquing) within SymbolTable.cpp. 3) This allows SymbolTable to hold a DenseMap instead of a StringMap (which again copies the string data and slows lookup). This is a moderately invasive patch, so I kept a lot of compatibility APIs around. It would be nice to explore changing getName() to return a StringAttr for example (right now you have to use getNameAttr()), and eliminate things like the StringRef version of getSymbol. Differential Revision: https://reviews.llvm.org/D108899
Enable FP16 complex FMA instructions. Ref.: https://software.intel.com/content/www/us/en/develop/download/intel-avx512-fp16-architecture-specification.html Reviewed By: LuoYuanke Differential Revision: https://reviews.llvm.org/D105269
The double precision KindCode was ignored when building the interface of specific intrinsic procedures leading to bad semantics checks. Differential Revision: https://reviews.llvm.org/D108828
This tutorial will guide you through the process of making a change to LLVM, and contributing it back to the LLVM project. We'll be making a change to Clang, but the steps for other parts of LLVM are the same. Even though the change we'll be making is simple, we're going to cover steps like building LLVM, running the tests, and code review. This is good practice, and you'll be prepared for making larger changes. Authors: @meikeb , @gribozavr Commit: Zhiqian Xia PS - This is a duplicate revision of https://reviews.llvm.org/D100714 which was actually used for patch review. Reviewed By: kuhnel Differential Revision: https://reviews.llvm.org/D108267
After applying VPlan-to-VPlan transformations, using IR references to query VPlan values may be incorrect, as the IR is not in sync with the VPlan any longer. To better detect such mis-matches, this patch introduces a new flag to VPlans to indicate whether it is safe to query VPValues using IR values. getVPValue is updated to assert if it is called when the flag indicates it is not safe any longer. There is an escape hatch via an extra argument, because there are 3 places that need to be fixed first. Those are 1. truncateToMinimalBitwidths 2. clearReductionWrapFlags 3. fixLCSSAPHIs As a first step, this flag will help preventing new code from violating this property. Any suggestions with respect to naming very welcome! Reviewed By: Ayal Differential Revision: https://reviews.llvm.org/D108573
Differential Revision: https://reviews.llvm.org/D108687
GET_COMMAND_ARGUMENT takes a lot of optional arguments: VALUE, LENGTH, STATUS and ERRMSG. This patch breaks up the interface into 2 different functions: * One for getting the LENGTH of an argument. * One for getting the VALUE and the ERRMSG of an argument. This returns the STATUS, which can be easily ignored by lowering if it is missing in the invocation. Differential Revision: https://reviews.llvm.org/D108688
This patch emits DW_TAG_namelist and DW_TAG_namelist_item for fortran namelist variables. DICompositeType is extended to support this fortran feature. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D108553
Add a support for handling fork/vfork stops in LLGS client. At this point, it only sends a detach packet for the newly forked child (and implicitly resumes the parent). Differential Revision: https://reviews.llvm.org/D100206
We currently don't simplify anything here, but we can.
`isValidRewrite()` checks that the both the original SCEV, and the rewrite SCEV have the same base pointer. I //believe//, after all the recent SCEV improvements, this invariant is already enforced by SCEV itself. I originally tried changing it into an assert in D108043, but that showed that it triggers on e.g. https://reviews.llvm.org/D108043#2946621, where SCEV manages to forward the store to load, test added. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D108655
41d4aa7 introduced incorrect code in extraTraitClassDeclaration: `this` refers to the trait class and not the operation class so `->getContext()` is not valid. Use `$_op` instead.
The option `--gdb-index` should be passed to linker if compiler is invoked with `-gsplit-dwarf` option. This allows debugger to locate the appropriate units quickly. See "Invocation" section here: https://gcc.gnu.org/wiki/DebugFission Suggested by @dblaikie here: https://reviews.llvm.org/D68556#1698442 Differential Revision: https://reviews.llvm.org/D108776
…eded Previously, we'd expand *ALL* the SCEV's eagerly, because we needed to check with `isValidRewrite()`, and discard bad rewrite candidates, but now that we do not do that, we also don't need to always expand. In particular, this avoids expanding potentially-huge SCEV's that we would discard anyways because they are high-cost and we aren't rewriting aggressively.
Reviewed By: melver Differential Revision: https://reviews.llvm.org/D108907
…split-dwarf` Follow-up of https://reviews.llvm.org/D108776
This can just be a default argument.
…re all target-specific costs. NFCI. The GLM/SLM special cases still get tested first but after the the MUL/DIV/REM pattern detection - this will be necessary for when we make the SLM vXi32 MUL canonicalization generic to improve PMULLW/PMULHW/PMADDDW cost support etc.
Clang only adds GCC paths for RHEL <= 7 'devtoolset-<N>' Software Collections (SCL). This generalizes this support to also include the 'gcc-toolset-10' SCL in RHEL/CentOS 8. Reviewed By: stephan.dollberg Differential Revision: https://reviews.llvm.org/D108908
After 41d4aa7, some builder.getStringAttr calls in FIR were wrong.
If we encounter a new debug value, describing the same parameter, we should stop tracking the parameter's Entry Value. At that point, in some cases, the Transfer which uses the parameter's Entry Value, is already emitted. Thanks to the RemoveRedundantDebugValues pass, many problems with incorrect instruction order and number of DBG_VALUEs are fixed. However, we still cannot rely on the rule that each new debug value is set by the previous non-debug instruction in Machine Basic Block. When new parameter debug value triggers removal of Backup Entry Value for the same parameter, do the cleanup of Transfers emitted from Backup Entry Values. Get the Transfer Instruction which created the new debug value and search for debug values already emitted from the to-be-deleted Backup Entry Value and attached to the Transfer Instruction. If found, delete the Transfer and remove "primary" Entry Value Var Loc from OpenRanges. This patch fixes PR47628. Patch by Nikola Tesic. Differential revision: https://reviews.llvm.org/D106856
Previously, if no column was specified, ResolveSymbolContext would take the first match returned by FindLineEntryIndexByFileIndex, and reuse it to find subsequent exact matches. With the introduction of columns, columns are now considered when matching the line entries. This leads to a problem if one wants to get all existing line entries that match that line, since now the column is also used for the exact match. This way, all line entries are filtered out that have a different column number, but the same line number. This patch changes that by ignoring the column information of the first match if the original request of ResolveSymbolContext was also ignoring it. Reviewed By: mib Differential Revision: https://reviews.llvm.org/D108816
… using file path. When I run a lldb command that uses filename completion, if I enter a string that is not only a filename but also a string with a non-file name string added, such as "./" that is relative path string , it will crash as soon as I press the [Tab] key. For example, debugging an executable file named "hello" that is compiled from a file named "hello.c" , and I’ll put a breakpoint on line 3 of hello.c. ``` $ lldb ./hello (lldb) breakpoint set --file hello.c --line 3 ``` This is not a problem, but if I set "--file ./hello." and then press [Tab] key to complete file name, lldb crashes. ``` $ lldb ./hello (lldb) breakpoint set --file ./hello.terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::substr: __pos (which is 8) > this->size() (which is 7) ``` The crash was caused because substr() (in lldb/source/Host/common/Editline.cpp) cut out string which size is user's input string from the completion string. I modified the code that erase the user's intput string from current line and then add the completion string. Differential Revision: https://reviews.llvm.org/D108817
…empty members This came up during the Windows bot failure discussing after D105471 . See also 3d9a9fa .
- Rename test files to follow conventions better - Split constructor tests that were in a single file - Add missing tests for take_view and transform_view's default constructors - Add missing tests for transform_view's view/function constructor - Fix include guards - Mark some tests as being specific to libc++ Differential Revision: https://reviews.llvm.org/D108829
…getParser.cpp ...that is located under llvm/lib/Support/. Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D108423
And add a test case to illustrate that we do in fact produce the right result for the multiple exit case. I have gotten myself confused at least three times when reading this code, so clarify to prevent future confusion.
Mark LWG3348 as complete. The `__cpp_lib_unwrap_ref` feature test macro was placed in `<functional>` in 466df17 Differential Revision: https://reviews.llvm.org/D108920
Only enforce that ptr* is illegal if the base type is a simple type, not when it is something like %ty, where %ty may resolve to an opaque pointer in force-opaque-pointers mode. Differential Revision: https://reviews.llvm.org/D108876
…line contexts. Md5 hashing is expansive. Using a hash map to look up already computed GUID for dwarf names. Saw a 2% build time improvement on an internal large application. Reviewed By: wenlei Differential Revision: https://reviews.llvm.org/D108722
This reverts commit 84cbd71. This commit breaks one of the internal tests. As agreed with Alexey I will provide the reproducer later.
Empty packs in the non-final position would result in an extra ", ". Empty packs in the final position would result in missing the space between trailing >>.
…es to 0 [-Werror=undef] Differential Revision: https://reviews.llvm.org/D108896
The backend generally uses 64-bit immediates (e.g. what MachineOperand::getImm() returns), so use that for analyzeCompare() and optimizeCompareInst() as well. This avoids truncation for targets that support immediates larger 32-bit. In particular, we can avoid the bugprone value normalization hack in the AArch64 target. This is a followup to D108076. Differential Revision: https://reviews.llvm.org/D108875
- Move a few variables closer to their uses, remove some completely (no behavior change) - Add some comments - Make maxPotentialThunks include calls to stubs. It's possible that an earlier call to a stub late in the stub table will need a thunk, and that inserted thunk could push a stub earlier in the stub table out of range. This is unlikely to happen, but usually there are way fewer stub calls than non-stub calls, so if we're doing a conservative approximation here we might as well do it correctly. (For chromium's unit_tests target, 134421/242639 stub calls are direct calls without this change, compared to 134408/242639 with this change) No real, meaningful behavior difference. Differential Revision: https://reviews.llvm.org/D108924
The min/max intrinsics are not yet canonical, but when they are the tail predications analysis will change from treating them like icmp to treating them like intrinsics. Unfortunately, they can currently produce better code by not being tail predicated thanks to the vectorizer picking higher VF's and the backend folding to better instructions (especially for saturate patterns). In the long run we will need to improve the vectorizers cost modelling, recognizing the instruction directly, but in the meantime this treats min/max as before to prevent performance regressions.
Added description of jump table and G_JUMP_TABLE opcode. Differential Revision: https://reviews.llvm.org/D107630
It looks like this array was missed in 4276d4a Fixed tests that expected `elements` to be empty or depeneded on the order of the empty DINode. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D107024
in DebugHandlerBase::isUnsignedDIType. Differential Revision: https://reviews.llvm.org/D108559
This fixes -isystem/-L/-Wl,-rpath paths when -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on is used (https://reviews.llvm.org/D107799#2969650). * `-isystem path/to/build/generic-cxx17/include/c++/v1`. `build/generic-cxx17/include/x86_64-unknown-linux-gnu/c++/v1 (__config_site)` is missing. * `-L path/to/build/generic-cxx17/lib`. Should be `build/generic-cxx17/lib/x86_64-unknown-linux-gnu` instead Reviewed By: ldionne, phosek, #libc Differential Revision: https://reviews.llvm.org/D108836
Adds patterns to match the EOR3 instruction. Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D108793
Implement folding of the transformational intrinsic function CSHIFT for all types. Differential Revision: https://reviews.llvm.org/D108931
… zero When expanding a SMULFIXSAT ISD node (usually originating from a smul.fix.sat intrinsic) we've applied some optimizations for the special case when the scale is zero. The idea has been that it would be cheaper to use an SMULO instruction (if legal) to perform the multiplication and at the same time detect any overflow. And in case of overflow we could use some SELECT:s to replace the result with the saturated min/max value. The only tricky part is to know if we overflowed on the min or max value, i.e. if the product is positive or negative. Unfortunately the implementation has been incorrect as it has looked at the product returned by the SMULO to determine the sign of the product. In case of overflow that product is truncated and won't give us the correct sign bit. This patch is adding an extra XOR of the multiplication operands, which is used to determine the sign of the non truncated product. This patch fixes PR51677. Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D108938
…TO_UINT when input is SoftPromoteHalf. Instead of splitting off the fp16 to float conversion and generating a libcall, we should split the operation into fp16 to float and float to integer operations. This will allow the float to integer conversion to go through any custom handling the target has. If the target doesn't have custom handling then we should come back to ExpandIntRes_FP_TO_SINT/ ExpandIntRes_FP_TO_UINT automatically to create the libcall. This avoids generating libcalls on 32-bit X86. These library functions may not exist in 32-bit libgcc. At least for LLVM, we never generate them when hardware floating point instructions are available. Differential Revision: https://reviews.llvm.org/D108933
…connected to add the bias at the end of the convolution Made to adjust for a modification to the tiling algorithm Reviewed By: rsuderman Differential Revision: https://reviews.llvm.org/D108746
Forward declare RecurrenceDescriptor and include IVDescritor.h only in implementation code that actually needs it.
…ather than IR instruction Currently, the IROutliner uses a simple metric to outline the largest amount of IR possible to outline first if it fits the cost model. This is model loses out on smaller blocks of code that have higher reductions in cost that are contained within larger blocks of IR. This reverses the order, where we calculate all of the costs first, and then reorder and extract items based on the calculated results. Reviewers: paquette Differential Revision: https://reviews.llvm.org/D106440
There is not cleanup to be done for the mutex type so mtx_destroy does nothing.
… than once so we can override it via clang's CLI if necessary.
In D87099, the mangler learned to quote export directives that contain special characters. Only alhpanumerical characters as well as '_', '$', '.' and '@' were exmpt from this quoting. However, at least binutils considers an unquoted '.' to be syntax and object files containing such symbols will cause errors during linking. Fix that by removing '.' from the list of allowed exemptions. Differential Revision: https://reviews.llvm.org/D100359
Fix minor typos in FPUtil comments. Reviewed By: michaelrj Differential Revision: https://reviews.llvm.org/D108952
pull bot
pushed a commit
that referenced
this pull request
May 6, 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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )