summaryrefslogtreecommitdiffstats
path: root/lldb/lit
Commit message (Collapse)AuthorAgeFilesLines
...
* DWARF: Fix address range support in mixed 4+5 scenarioPavel Labath2019-05-292-1/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: debug_ranges got renamed to debug_rnglists in DWARF 5. Prior to this patch lldb was just picking the first section it could find in the file, and using that for all address ranges lookups. This is not correct in case the file contains a mixture of compile units with various standard versions (not a completely unlikely scenario). In this patch I make lldb support reading from both sections simulaneously, and decide the correct section to use based on the version number of the compile unit. SymbolFileDWARF::DebugRanges is split into GetDebugRanges and GetDebugRngLists (the first one is renamed mainly so we can catch all incorrect usages). I tried to structure the code similarly to how llvm handles this logic (hence DWARFUnit::FindRnglistFromOffset/Index), but the implementations are still relatively far from each other. Reviewers: JDevlieghere, aprantl, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D62302 llvm-svn: 361938
* [CMake] Folder structure for generated Xcode project to cover more targetsStefan Granitz2019-05-281-1/+1
| | | | llvm-svn: 361799
* XFAIL prefer-debug-over-eh-frame.test on darwinPavel Labath2019-05-271-1/+2
| | | | | | | | | | | | | debug_frame does not seem to work on darwin, so there is nothing to prefer. Adding `-g` to the compiler command line is enough to get the __debug_frame section added to the dsym file. Though lldb then finds the section, and correctly assigns the section type to it, this does not seem to be enough to get lldb to actually use this section for unwinding. llvm-svn: 361760
* DWARF: Add a simple test exercising debug_loc parsingPavel Labath2019-05-271-0/+117
| | | | llvm-svn: 361759
* FuncUnwinders: prefer debug_frame over eh_framePavel Labath2019-05-272-0/+61
| | | | | | | | | | | | | | | The two sections usually contain the same information, and we rarely have both kinds of entries for a single function. However, in theory the debug_frame plan can be more complete, whereas eh_frame is only required to be correct at places where exceptions can be thrown. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D62374 llvm-svn: 361758
* [FuncUnwinders] Use "symbol file" unwind plans for unwindingPavel Labath2019-05-244-0/+73
| | | | | | | | | | | | | | | | | Summary: Previous patch (r360409) introduced the "symbol file unwind plan" concept, but that plan wasn't used for unwinding yet. With this patch, we start to consider the new plan as a possible strategy for both synchronous and asynchronous unwinding. I also add a test that asserts that unwinding via breakpad STACK CFI info works end-to-end. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits, amccarth, markmentovai Differential Revision: https://reviews.llvm.org/D61853 llvm-svn: 361618
* DWARF: Implement DW_AT_signature lookup for type unit supportPavel Labath2019-05-246-4/+178
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the main feature of type units. When completing a type, if we encounter a DW_AT_signature attribute, we use it's value to lookup the complete definition of the type in the relevant type unit. To enable this lookup, we build up a map of all type units in a symbol file when parsing the units. Then we consult this map when resolving the DW_AT_signature attribute. I include add a couple of tests which exercise the type lookup feature, including one that ensure we do something reasonable in case we fail to lookup the type. A lot of the ideas in this patch have been taken from D32167 and D61505. Reviewers: clayborg, JDevlieghere, aprantl, alexshap Subscribers: mgrang, lldb-commits Differential Revision: https://reviews.llvm.org/D62246 llvm-svn: 361603
* DWARFContext: Make loading of sections thread-safePavel Labath2019-05-241-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: SymbolFileDWARF used to load debug sections in a thread-safe manner. When we moved to DWARFContext, we dropped the thread-safe part, because we thought it was not necessary. It turns out this was only mostly correct. The "mostly" part is there because this is a problem only if we use the manual index, as that is the only source of intra-module paralelism. Also, this only seems to occur for extremely simple files (like the ones I've been creating for tests lately), where we've managed to start indexing before loading the debug_str section. Then, two threads start to load the section simultaneously and produce wrong results. On more complex files, something seems to be loading the debug_str section before we start indexing, as I haven't been able to reproduce this there, but I have not investigated what it is. I've tried to come up with a test for this, but I haven't been able to reproduce the problem reliably. Still, while doing so, I created a way to generate many compile units on demand. Given that most of our tests work with only one or two compile units, it seems like this could be useful anyway. Reviewers: aprantl, JDevlieghere, clayborg Subscribers: arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D62316 llvm-svn: 361602
* Add REQUIRES: lld to debug-types-address-ranges.sPavel Labath2019-05-231-0/+2
| | | | | | This should fix the green dragon bots. llvm-svn: 361481
* DWARF: Don't compute address ranges for type unitsPavel Labath2019-05-231-0/+338
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Type units don't describe any code, so they should never be the result of any address lookup queries. Previously, we would compute the address ranges for the type units for via the line tables they reference because the type units looked a lot like line-tables-only compile units. However, this is not correct, as the line tables are only referenced from type units so that other declarations can use the file names contained in them. In this patch I make the BuildAddressRangeTable function virtual, and implement it only for compile units. Testing this was a bit tricky, because the behavior depends on the order in which we add things to the address range map. This rarely caused a problem with DWARF v4 type units, as they are always added after all CUs. It happened more frequently with DWARF v5, as there clang emits the type units first. However, this is still not something that it is required to do, so for testing I've created an assembly file where I've deliberately sandwiched a compile unit between two type units, which should isolate us from both changes in how the compiler emits the units and changes in the order we process them. Reviewers: clayborg, aprantl, JDevlieghere Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D62178 llvm-svn: 361465
* DWARF: Add debug_ranges/rnglists testsPavel Labath2019-05-223-0/+219
| | | | | | | | | | | | | | | .debug_ranges parsing is not well tested [citation needed] because this section tends to be only used in optimized code, and we don't build optimized executables in our tests, as they produce unpredictable results. This patch aims to add some very simple tests for parsing static range data, which can serve as a first line of defense in case things break. I also include one XFAILed test, which demonstrates that we don't correctly handle mixed DWARF v5 and v4 ranges in a single file. llvm-svn: 361373
* DWARF: Introduce DWARFTypeUnit classPavel Labath2019-05-225-1/+113
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces the DWARFTypeUnit class, and teaches lldb to parse type units out of both the debug_types section (DWARF v4), and from the regular debug_info section (DWARF v5). The most important piece of functionality - resolving DW_AT_signatures to connect type forward declarations to their definitions - is not implemented here, but even without that, a lot of functionality becomes available. I've added tests for the commands that start to work after this patch. The changes in this patch were greatly inspired by D61505, which in turn took over changes from D32167. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: mgorny, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D62008 llvm-svn: 361360
* [lldb] [lit] Skip more tests when Python is unavailableMichal Gorny2019-05-192-0/+3
| | | | | | | | LocalLLDBInit.test requires Python module loading support. CommandScriptImmediateOutput tests are specific to running scripts. Disable all of them when Python support is disabled. llvm-svn: 361115
* [lldb] [lit] Driver/TestConvenienceVariables.test requires PythonMichal Gorny2019-05-192-1/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D62096 llvm-svn: 361114
* [CommandInterpreter] Fix trailing blanks after `all` or [0-9]+ for btStella Stamenova2019-05-171-1/+1
| | | | | | The change that was committed for this used \\s to match spaces which does not work correctly on all platforms. Using [:space:] makes the test pass on both Linux and Windows llvm-svn: 361064
* [CommandInterpreter] Accept blanks after `all` or [0-9]+ for bt.Davide Italiano2019-05-171-0/+12
| | | | | | | | | | | Previously "bt all " would've failed as the regex didn't match them. Over the shoulder review by Jonas Devlieghere. <rdar://problem/50824935> llvm-svn: 360966
* DWARFContext: Return empty data extractors instead of null pointersPavel Labath2019-05-161-0/+63
| | | | | | | | | | | | | | | | | | | | | | | Summary: There are several reasons for doing this: - generally, there's no reason to differentiate between a section being absent and it being present, but empty - it matches more closely what llvm DWARF parser is doing (which also doesn't differentiate the two cases) - SymbolFileDWARF also doesn't differentiate the two cases, which makes porting the rest of sections easier - it fixes a bug in how the return-null-if-empty logic was implemented (it returned nullptr only the second time we tried to get the debug_aranges section), which meant that we hit an assert when trying to parse an empty-but-present section Reviewers: JDevlieghere, clayborg, aprantl Subscribers: zturner, lldb-commits Differential Revision: https://reviews.llvm.org/D61942 llvm-svn: 360874
* DWARF: Add ability to reference debug info coming from multiple sectionsPavel Labath2019-05-162-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the ability to precisely address debug info in situations when a single file can have more than one debug-info-bearing sections (as is the case with type units in DWARF v4). The changes here can be classified into roughly three categories: - the code which addresses a debug info by offset gets an additional argument, which specifies the section one should look into. - the DIERef class also gets an additional member variable specifying the section. This way, code dealing with DIERefs can know which section is the object referring to. - the user_id_t encoding steals one bit from the dwarf_id field to store the section. This means the total number of separate object files (apple .o, or normal .dwo) is limited to 2 billion, but that is fine as it's not possible to hit that number without switching to DWARF64 anyway. This patch is functionally equivalent to (and inspired by) the two patches (D61503 and D61504) by Jan Kratochvil, but there are differences in the implementation: - it uses an enum instead of a bool flag to differentiate the sections - it increases the size of DIERef struct instead of reducing the amount of addressable debug info - it sets up DWARFDebugInfo to store the units in a single vector instead of two. This sets us up for the future in which type units can also live in the debug_info section, and I believe it's cleaner because there's no need for unit index remapping There are no tests with this patch as this is essentially NFC until we start parsing type units from the debug_types section. Reviewers: JDevlieghere, clayborg, aprantl Subscribers: arphaman, jankratochvil, lldb-commits Differential Revision: https://reviews.llvm.org/D61908 llvm-svn: 360872
* [lldb] [lit] Pass --mode=compile to fix compiler-full-path.testMichal Gorny2019-05-151-4/+5
| | | | | | | | | Pass '--mode=compile' to fix compiler-full-path.test failure on NetBSD buildbot (apparently due to lack of 'link' executable). Fixes r360355. Acked by Pavel Labath. llvm-svn: 360761
* [lldb] [lit] Fix whitespace in matches for remaining AVX512 testsMichal Gorny2019-05-153-40/+40
| | | | llvm-svn: 360744
* [lit/Register] Fix matching of the output.Davide Italiano2019-05-141-32/+32
| | | | llvm-svn: 360725
* Disable TestEnvironment on WindowsJonas Devlieghere2019-05-131-0/+2
| | | | | | | | | | | | | | The input source file seems to be triggering an error in the Visual Studio headers. > xstddef:338:2: error: ''auto' return without trailing return type; > deduced return types are a C++14 extension I tried converting the test to use the %build stuff Zachary added, but that seems to be missing some Darwin support. Disabling the test on Windows in the meantime. llvm-svn: 360624
* Merge target and launch info environmentsJonas Devlieghere2019-05-132-0/+14
| | | | | | | | | | | Before this change we were overriding the launch info environment with the target environment. This meant that the environment variables passed to `process launch --environment <>` were lost. Instead of replacing the environment, we should merge them. Differential revision: https://reviews.llvm.org/D61864 llvm-svn: 360612
* [NativePDB] Fix tests after r360569Aleksandr Urakov2019-05-131-6/+0
| | | | llvm-svn: 360587
* Add REQUIRES: windows to NativePDB/stack_unwinding01.cppPavel Labath2019-05-131-2/+2
| | | | | | | The test runs the compiled executable. As such, it can only work on windows hosts. llvm-svn: 360576
* Breakpad: Generate unwind plans from STACK CFI recordsPavel Labath2019-05-133-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements the GetUnwindPlan interface (added in the previous patch) for SymbolFileBreakpad, and uses it to generate unwind plans from STACK CFI records in breakpad files. We first perform a light-weight parse of the breakpad in order to build up a map of regions covered by the unwind info so that we can later jump to the right record when we need to unwind a specific function. The actual parsing is relatively straight-forward, as the STACK CFI records are just another (text) form of the eh_frame unwind instructions, and the same goes for lldb's UnwindPlans. The newly-introduced PostfixExpression API is used to convert the breakpad postfix expressions into DWARF. The generated dwarf expressions are stored in a BumpPtrAllocator, as the UnwindPlan does not take ownership of the expression data it references (usually this is static data in an object file, so special ownership is needed). At this moment the generated unwind plans aren't used in the actual unwind machinery (only in the image show-unwind command), but that is coming in a separate patch. Reviewers: amccarth, clayborg, markmentovai Subscribers: aprantl, jasonmolenda, lldb-commits Differential Revision: https://reviews.llvm.org/D61733 llvm-svn: 360574
* Fix flakiness in lldb lit testStefan Granitz2019-05-131-1/+0
| | | | | | | | Messages "breakpoint locations added" and "process stopped" may come out of order. Differential Revision: https://reviews.llvm.org/D61611#anchor-1499662 llvm-svn: 360571
* [NativePDB] Support member function types in PdbAstBuilderAleksandr Urakov2019-05-132-0/+56
| | | | | | | | | | | | | | | | | Summary: This patch implements missing case in PdbAstBuilder::CreateType for LF_MFUNCTION. This is necessary, for example, in stack unwinding of struct methods. Reviewers: amccarth, aleksandr.urakov Reviewed By: amccarth Subscribers: abidh, teemperor, lldb-commits, leonid.mashinskiy Differential Revision: https://reviews.llvm.org/D61128 llvm-svn: 360569
* @skipIfLinux flaky lldb-mi testsPavel Labath2019-05-132-0/+2
| | | | llvm-svn: 360564
* [CMake] Add lli to LLDB_TEST_DEPSFangrui Song2019-05-131-0/+1
| | | | | | | lli is used by lit/Breakpoint/jitbp_elf.test I had a test failure when running check-lldb-lit because my lli was stale. llvm-svn: 360557
* Fix file names in file headers. NFCFangrui Song2019-05-131-1/+1
| | | | llvm-svn: 360554
* [lldb] [lit] Fix clobbers in x86_64 register testMichal Gorny2019-05-101-2/+2
| | | | llvm-svn: 360423
* Use UNSUPPORTED: system-windows instead of REQUIRES: nowindows or ↵Stella Stamenova2019-05-091-1/+1
| | | | | | UNSUPPORTED: windows. nowindows is not currently defined and windows does not cover all cases. system-windows is also consistent with how other platforms are used. llvm-svn: 360368
* [lldb] build.py: fix behavior when passing --compiler=/path/to/compilerJorge Gorbe Moya2019-05-092-6/+16
| | | | | | | | | | | | | | | All the other paths in the find_toolchain function return a tuple (detected_toolchain_type, compiler_path), but when the parameter to --compiler is not one of the predefined names it only returns the detected toolchain type, which causes an error when trying to unpack the result. This patch changes it to return also the compiler path passed as a parameter. Differential Revision: https://reviews.llvm.org/D61713 llvm-svn: 360355
* [JITLoaderGDB] Set eTypeJIT for objects read from JIT descriptorsStefan Granitz2019-05-093-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: First part of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's is still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209 The address of the breakpoint site is corrupt: the 0x4 value we end up with, looks like an offset on a zero base address. When we parse the ELF section headers from the JIT descriptor, the load address for the text section we find in `header.sh_addr` is correct. The bug manifests in `VMAddressProvider::GetVMRange(const ELFSectionHeader &)` (follow it from `ObjectFileELF::CreateSections()`). Here we think the object type was `eTypeObjectFile` and unleash some extra logic [1] which essentially overwrites the address with a zero value. The object type is deduced from the ELF header's `e_type` in `ObjectFileELF::CalculateType()`. It never returns `eTypeJIT`, because the ELF header has no representation for it [2]. Instead the in-memory ELF object states `ET_REL`, which leads to `eTypeObjectFile`. This is what we get from `lli` at least since 3.x. (Might it be better to write `ET_EXEC` on the JIT side instead? In fact, relocations were already applied at this point, so "Relocatable" is not quite exact.) So, this patch proposes to set `eTypeJIT` explicitly whenever we read from a JIT descriptor. In `ObjectFileELF::CreateSections()` we can then call `GetType()`, which returns the explicit value or otherwise falls back to `CalculateType()`. LLDB then sets the breakpoint successfully. Next step: debug info. ``` Process 1056 stopped * thread #1, name = 'lli', stop reason = breakpoint 1.2 frame #0: 0x00007ffff7ff7000 JIT(0x3ba2030)`jitbp() JIT(0x3ba2030)`jitbp: -> 0x7ffff7ff7000 <+0>: pushq %rbp 0x7ffff7ff7001 <+1>: movq %rsp, %rbp 0x7ffff7ff7004 <+4>: movabsq $0x7ffff7ff6000, %rdi ; imm = 0x7FFFF7FF6000 0x7ffff7ff700e <+14>: movabsq $0x7ffff6697e80, %rcx ; imm = 0x7FFFF6697E80 ``` [1] It was first introduced with https://reviews.llvm.org/D38142#change-lF6csxV8HdlL, which has also been the original breaking change. The code has changed a lot since then. [2] ELF object types: https://github.com/llvm/llvm-project/blob/2d2277f5/llvm/include/llvm/BinaryFormat/ELF.h#L110 Reviewers: labath, JDevlieghere, bkoropoff, clayborg, espindola, alexshap, stella.stamenova Reviewed By: labath, clayborg Subscribers: probinson, emaste, aprantl, arichardson, MaskRay, AlexDenisov, yurydelendik, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61611 llvm-svn: 360354
* Propagate command interpreter errors from lldlbinitJonas Devlieghere2019-05-083-0/+4
| | | | | | | | | | | | | | This patch ensures that we propagate errors coming from the lldbinit file trough the command/script interpreter. Before, if you did something like command script import syntax_error.py, and the python file contained a syntax error, lldb wouldn't tell you about it. This changes with the current patch: errors are now propagated by default. PS: Jim authored this change and I added testing. Differential revision: https://reviews.llvm.org/D61579 llvm-svn: 360216
* Disable eh-frame-dwarf-unwind.test on windowsPavel Labath2019-05-071-0/+1
| | | | | | | It fails on the windows bot. Disable until I can figure out what's the reason. llvm-svn: 360182
* [Driver] Add command line option to allow loading local lldbinit file.Jonas Devlieghere2019-05-071-2/+5
| | | | | | | | | This patch adds a command line flag that allows lldb to load local lldbinit files. Differential revision: https://reviews.llvm.org/D61578 llvm-svn: 360172
* Make eh-frame-dwarf-unwind.test run on non-linux platformsPavel Labath2019-05-073-17/+10
| | | | | | | This was meant to be a part of r360158, but I forgot to squash the commits before pushing. llvm-svn: 360168
* RegisterContextLLDB: Push CFA value on DWARF stack when evaluating register ↵Pavel Labath2019-05-072-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | expressions Summary: This behavior is specified in the Section 6.4.2.3 (Register Rule instructions) of the DWARF4 spec. We were not doing that, which meant that any register rule which was relying on the cfa value being there was not evaluated correctly (it was aborted due to "out of bounds" access). I'm not sure how come this wasn't noticed before, but I guess this has something to do with the fact that dwarf unwind expressions are not used very often, and when they are, the situation is so complicated that the CFA is of no use. I noticed this when I started emitting dwarf expressions for the unwind information present in breakpad symbol files. Reviewers: jasonmolenda, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D61018 llvm-svn: 360158
* [lldb] [lit] Update constants in write Register testsMichal Gorny2019-05-078-256/+256
| | | | | | Update the constants used for XMM/YMM/ZMM registers to match read tests. llvm-svn: 360154
* [lldb] [lit] Fix Register tests to reference arrays via %0 and %1Michal Gorny2019-05-078-189/+180
| | | | | | | | Fix Register tests to reference memory access to arrays via %0 and %1, rather than via referencing %rax and %rbx directly. This fixes test build failures on 32-bit x86. llvm-svn: 360148
* [Driver] Change the way we deal with local lldbinit files.Jonas Devlieghere2019-05-063-0/+15
| | | | | | | | | | | | | | | | Currently we have special handling for local lldbinit files in the driver. At the same time, we have an SB API named `SourceInitFileInCurrentWorkingDirectory` that does the same thing. This patch removes the special handling from the driver and uses the API instead. In addition to the obvious advantages of having one canonical way of doing things and removing code duplication, this change also means that the code path is the same for global and local lldb init files. Differential revision: https://reviews.llvm.org/D61577 llvm-svn: 360077
* [lldb] [lit] Use more readable consts and arrays in register read testsMichal Gorny2019-05-0612-490/+472
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace the constants used for r8/mm/xmm/ymm/zmm tests with something more readable to ease debugging in case of failures (0x00 0x01 ...). While at it, put the constants in array and copy them from memory to simplify inline asm. The original constants grew out of necessity. The xmm constants were 'weird' because they were intended to be different from mm constants (as that was necessary to catch NetBSD implementation bug). The ymm constants were made even weirded to not even partially collide with other xmm registers (not saying it made sense, just how it was done). Then, zmm constants were once again designed to avoid accidental collisions with xmm and ymm constants, and at the same the 16 extra registers required even more shuffling. The new constants are meant to be more user-readable, so that a mistake could be easily spotted. All of xmm, ymm and zmm tests use a sequence of {0x00 0x01 0x02 ...}, shifted by 1 for every register. This should provide enough uniquity, and space for future increase in number of registers. Since mm and r8..r15 are printed as uint64_t rather than byte-by-byte, they use 0x000102... As a result, on x86 endianness takes care of making mm different than xmm. The use of arrays is something I had to learn for zmm write tests. It avoids having to specify all the input values separately, and makes GCC happy about zmm-read test (it was rejected previously because of hitting a limit of 30 constraints). llvm-svn: 360041
* [lldb] [lit] Simplify general-purpose register testsMichal Gorny2019-05-054-61/+27
| | | | | | | | | Use output constraints for specific general-purpose registers in order to simplify the tests. They save us from having to manually put the values in correct registers, and reduce the number of registers needed as a result. llvm-svn: 359978
* [lldb] [lit] Fix more filename mismatches in Register testsMichal Gorny2019-05-052-2/+2
| | | | llvm-svn: 359977
* [test] Make check more strictJonas Devlieghere2019-05-031-2/+2
| | | | | | | Before this change the test would always pass if the path to the test contained the number 11 in it. Thanks to Ted for pointing this out. llvm-svn: 359930
* Make lldb-mi optional and change how we deal with missing tools in litJonas Devlieghere2019-05-033-7/+1
| | | | | | | | | We don't need the variables in lit, we can use the capabilities to check if the utility exists. Differential revision: https://reviews.llvm.org/D61533 llvm-svn: 359926
* [lldb] [lit] Add write tests for AVX-512 registers (zmm, xmm15+, ymm15+)Michal Gorny2019-05-025-0/+320
| | | | | | Differential Revision: https://reviews.llvm.org/D61439 llvm-svn: 359797
* Reinstate xfail-darwin in x86-64-ymm-write.testPavel Labath2019-05-021-0/+1
| | | | | | It turns out writing into ymm registers really does not work there. llvm-svn: 359795
OpenPOWER on IntegriCloud