- Aug 14, 2020
-
-
Raphael Isemann authored
This test is flaky on Green Dragon as it often fails when the process state is "Invalid" in the assert: self.assertEqual(process.GetState(), lldb.eStateExited) It seems this is related to just doing "run" which apparently invalidates the Target's process in case it's still running and needs to be restarted. Just doing 'continue' on the process (and ignoring the error in case it already finished) prevents that and makes this consistently pass for me. Just pushing this out to get Green Dragon back online. -
Pavel Labath authored
The search for the complete class definition can also produce entries which are not of the expected type. This can happen for instance when there is a function with the same name as the class we're looking up (which means that the class needs to be disambiguated with the struct/class tag in most contexts). Previously we were just picking the first Decl that the lookup returned, which later caused crashes or assertion failures if it was not of the correct type. This patch changes that to search for an entry of the correct type. Differential Revision: https://reviews.llvm.org/D85904
-
Pavel Labath authored
This didn't cause test failures since this variable is only used during connection shutdown.
-
Stefan Gränitz authored
-
Raphael Isemann authored
There are two implementations for `TypeSystemMap::GetTypeSystemForLanguage` which are both identical beside one taking a `Module` and one taking a `Target` (and then passing that argument to the `TypeSystem::CreateInstance` function). This merges both implementations into one function with a lambda that wraps the different calls to `TypeSystem::CreateInstance`. Reviewed By: #lldb, JDevlieghere Differential Revision: https://reviews.llvm.org/D82537
-
Stefan Gränitz authored
-
Mehdi Amini authored
This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand: - the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context. - Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline. This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled.
-
Shu Anzai authored
This is relanding D81001. The patch originally failed as on newer editline versions it seems CC_REFRESH will move the cursor to the start of the line via \r and then back to the original position. On older editline versions like the one used by default on macOS, CC_REFRESH doesn't move the cursor at all. As the patch changed the way we handle tab completion (previously we did REDISPLAY but now we're doing CC_REFRESH), this caused a few completion tests to receive this unexpected cursor movement in the output stream. This patch updates those tests to also accept output that contains the specific cursor movement commands (\r and then \x1b[XC). lldbpexpect.py received an utility method for generating the cursor movement escape sequence. Original summary: I implemented autosuggestion if there is one possible suggestion. I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called. Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k. Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it. Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now. Reviewed By: teemperor, JDevlieghere, #lldb Differential Revision: https://reviews.llvm.org/D81001
-
Stefan Gränitz authored
This loop caused me a little headache once, because I didn't see the assigned variable is a member. The refactored version appears more readable to me. Differential Revision: https://reviews.llvm.org/D85922
-
Stefan Gränitz authored
This is analog to how LLJIT provides public access to all its layers. Differential Revision: https://reviews.llvm.org/D85921
-
Stefan Gränitz authored
This adds RemoteJITLinkMemoryManager is a new subclass of OrcRemoteTargetClient. It implements jitlink::JITLinkMemoryManager and targets the OrcRemoteTargetRPCAPI. Behavior should be very similar to RemoteRTDyldMemoryManager. The essential differnce with JITLink is that allocations work in isolation from its memory manager. Thus, the RemoteJITLinkMemoryManager might be seen as "JITLink allocation factory". RPCMMAlloc is another subclass of OrcRemoteTargetClient and implements the actual functionality. It allocates working memory on the host and target memory on the remote target. Upon finalization working memory is copied over to the tagrte address space. Finalization can be asynchronous for JITLink allocations, but I don't see that it makes a difference here. Differential Revision: https://reviews.llvm.org/D85919
-
Alex Zinenko authored
The convresion of memref cast operaitons from the Standard dialect to the LLVM dialect has been emitting bitcasts from a struct type to itself. Beyond being useless, such casts are invalid as bitcast does not operate on aggregate types. This kept working by accident because LLVM IR bitcast construction API skips the construction if types are equal before it verifies that the types are acceptable in a bitcast. Do not emit such bitcasts, the memref cast that only adds/erases size information is in fact a noop on the current descriptor as it always contains dynamic values for all sizes. Reviewed By: pifon2a Differential Revision: https://reviews.llvm.org/D85899
-
Alex Zinenko authored
We have been asking for this systematically, mention it in the documentation. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D85902
-
Sam Parker authored
Renamed to maybeLoweredToCall.
-
Frederik Gossen authored
Add custom assembly format for `shape.any` with variadic operands. Differential Revision: https://reviews.llvm.org/D85306
-
Pavel Labath authored
The function had very complicated signature, because it was trying to avoid making unnecessary copies of the Scalar object. However, this class is not hot enough to worry about these kinds of optimizations. My making copies unconditionally, we can simplify the function and all of its call sites. Differential Revision: https://reviews.llvm.org/D85906
-
Kirill Bobyrev authored
-
Aleksandr Platonov authored
`find_program(<VAR> ...)` sets <VAR> to <VAR>-NOTFOUND if nothing was found. So we need to compare <VAR> with "<VAR>-NOTFOUND" or just use `if([NOT] <VAR>)`, because `if(<VAR>)` is false if `<VAR>` ends in the suffix -NOTFOUND. Reviewed By: kbobyrev Differential Revision: https://reviews.llvm.org/D85958
-
Joachim Protze authored
Starting with 787eb0c6 I got spurious segmentation faults for some testcases. I could nail it down to `brel` trying to release the "memory" of the node allocated on the stack of __kmpc_omp_wait_deps. With this patch, you will see the assertion triggering for some of the tests in the test suite. My proposed solution for the issue is to just patch __kmpc_omp_wait_deps: ``` __kmp_init_node(&node); - node.dn.on_stack = 1; + // the stack owns the node + __kmp_node_ref(&node); ``` What do you think? Reviewed By: AndreyChurbanov Differential Revision: https://reviews.llvm.org/D84472
-
Kirill Bobyrev authored
Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D85815
-
Vitaly Buka authored
-
Mehdi Amini authored
-
Mehdi Amini authored
-
Gui Andrade authored
These functions won't ever unwind. This is useful for MemorySanitizer as it simplifies handling __atomic_load in particular. Differential Revision: https://reviews.llvm.org/D85573
-
LLVM GN Syncbot authored
-
Eduardo Caldas authored
* Switch to using directive on source files. * Remove unused `SyntaxTreeTest::addFile` Differential Revision: https://reviews.llvm.org/D85913
-
Raphael Isemann authored
When LLDB sees only one possible completion for an input, it will add a trailing space to the completion to signal that to the user. If the current argument is quoted, that also means LLDB needs to add the trailing quote to finish the current argument first. In case the user is in a function with only one local variable and is currently editing an empty line in the multiline expression editor, then we are in the unique situation where we can have a unique completion for an empty input line. (In a normal LLDB session this would never occur as empty input would just list all the possible commands). In this special situation our check if the current argument needs to receive a trailing quote will crash LLDB as there is no current argument and the completion code just unconditionally tries to access the current argument. This just adds the missing check if we even have a current argument before we check if we need to add a terminating quote character. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D85903
-
Sebastian Neubauer authored
PAL recently got support for multiple ELF sections and relocations, therefore we can now use .rodata sections instead of forcing constants into .text. Differential Revision: https://reviews.llvm.org/D85895
-
David Sherwood authored
The code wasn't taking into account that the two operands passed to ptest could be identical and was trying to erase them twice. Differential Revision: https://reviews.llvm.org/D85892
-
Sam Parker authored
When getUserCost was transitioned to use an explicit CostKind, TCK_CodeSize was used even though the original kind was implicitly SizeAndLatency so restore this behaviour. We now only query for CodeSize when optimising for minsize. I expect this to not change anything as, I think all, targets will currently return the same value for CodeSize and SizeLatency. Indeed I see no changes in the test suite for Arm, AArch64 and X86. Differential Revision: https://reviews.llvm.org/D85829
-
Igor Kudrin authored
dumpStringOffsetsSection() expects the size of a contribution to be correctly aligned. The patch adds the corresponding verifications for pre-v5 cases. Differential Revision: https://reviews.llvm.org/D85739
-
Arthur Eubanks authored
This reverts commit ab9fc8ba. Incorrect transformation if the result is used. Causes breakages, e.g. http://green.lab.llvm.org/green/job/test-suite-verify-machineinstrs-x86_64-O3/8193/
-
Chris Kennelly authored
Differential Revision: https://reviews.llvm.org/D85944
-
aartbik authored
Masked loading/storing in various forms can be optimized into simpler memory operations when the mask is all true or all false. Note that the backend does similar optimizations but doing this early may expose more opportunities for further optimizations. This further prepares progressively lowering transfer read and write into 1-D memory operations. Reviewed By: ThomasRaoux Differential Revision: https://reviews.llvm.org/D85769
-
Thomas Lively authored
-
Peter Collingbourne authored
This lets us support the scenario where a binary is linked from a mix of object files with both instrumented and non-instrumented globals. This is likely to occur on Android where the decision of whether to use instrumented globals is based on the API level, which is user-facing. Previously, in this scenario, it was possible for the comdat from one of the object files with non-instrumented globals to be selected, and since this comdat did not contain the note it would mean that the note would be missing in the linked binary and the globals' shadow memory would be left uninitialized, leading to a tag mismatch failure at runtime when accessing one of the instrumented globals. It is harmless to include the note when targeting a runtime that does not support instrumenting globals because it will just be ignored. Differential Revision: https://reviews.llvm.org/D85871
-
Yuanfang Chen authored
D83608 need this. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D85916
-
Ben Dunbobbin authored
This patch restricts the behaviour of referencing via .Lfoo$local local aliases, introduced in https://reviews.llvm.org/D73230, to STV_DEFAULT globals only. Hidden symbols via --fvisiblity=hidden (https://gcc.gnu.org/wiki/Visibility) is an important scenario. Benefits: - Improves the size of object files by using fewer STT_SECTION symbols. - The code reads a bit better (it was not obvious to me without going back to the code reviews why the canBenefitFromLocalAlias function currently doesn't consider visibility). - There is also a side benefit in restoring the effectiveness of the --wrap linker option and making the behavior of --wrap consistent between LTO and normal builds for references within a translation-unit. Note: this --wrap behavior (which is specific to LLD) should not be considered reliable. See comments on https://reviews.llvm.org/D73230 for more. Differential Revision: https://reviews.llvm.org/D85782
-
Arthur Eubanks authored
Previously ConstantFoldExtractElementInstruction() would only work with insertelement instructions, not contants. This properly handles insertelement constants as well. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D85865
-
Amy Huang authored
[DebugInfo] Add -fuse-ctor-homing cc1 flag so we can turn on constructor homing only if limited debug info is already on. This adds a cc1 flag to enable constructor homing but doesn't turn on debug info if it wasn't enabled already (which is what using -debug-info-kind=constructor does). This will be used for testing, and won't be needed anymore once ctor homing is used as default / merged into =limited. Bug to enable ctor homing: https://bugs.llvm.org/show_bug.cgi?id=46537 Differential Revision: https://reviews.llvm.org/D85799
-