summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* [X86][SSE] Cleanup SSE4A/SSE41/SSE42 intrinsics testsSimon Pilgrim2018-06-0211-2476/+3895
| | | | | | | | Ensure we cover 32/64-bit targets for SSE/AVX/AVX512 cases as necessary Added some missing encoding checks to SSE4A tests llvm-svn: 333828
* [X86][BMI2] Test i32 intrinsics on 32/64 bits + branch off i64 testsSimon Pilgrim2018-06-022-59/+249
| | | | | | | | | | I had to tweak the i32 tests so we check both reg-reg and reg-mem cases. I also added i64 load tests. Part of ongoing work to ensure we test all intrinsic style tests on 32 and 64 bit targets where possible. llvm-svn: 333827
* [X86][BMI1] Remove test for non-existent andn i16 instructionSimon Pilgrim2018-06-021-62/+0
| | | | llvm-svn: 333826
* [NEON] Support VLD1xN intrinsics in AArch32 mode (LLVM part)Ivan A. Kosarev2018-06-027-7/+456
| | | | | | | | | We currently support them only in AArch64. The NEON Reference, however, says they are 'ARMv7, ARMv8' intrinsics. Differential Revision: https://reviews.llvm.org/D47120 llvm-svn: 333825
* Revert r333819 "[NEON] Support VLD1xN intrinsics in AArch32 mode (Clang part)"Ivan A. Kosarev2018-06-027-456/+7
| | | | | | | | The LLVM part was committed instead of the Clang part. Differential Revision: https://reviews.llvm.org/D47121 llvm-svn: 333824
* [MC] Add assembler support for .cg_profile.Michael J. Spencer2018-06-0220-0/+367
| | | | | | | | | | | | | | | Object FIle Representation At codegen time this is emitted into the ELF file a pair of symbol indices and a weight. In assembly it looks like: .cg_profile a, b, 32 .cg_profile freq, a, 11 .cg_profile freq, b, 20 When writing an ELF file these are put into a SHT_LLVM_CALL_GRAPH_PROFILE (0x6fff4c02) section as (uint32_t, uint32_t, uint64_t) tuples as (from symbol index, to symbol index, weight). Differential Revision: https://reviews.llvm.org/D44965 llvm-svn: 333823
* [X86] Add tied source operand to AVX5124FMAPS and AVX5124VNNIW instructions.Craig Topper2018-06-021-20/+33
| | | | | | This doesn't affect the assembly or disassembly, but is more accurate. llvm-svn: 333822
* [X86] Fix warning message for AVX5124FMAPS and AVX5124VNNIW instructions in ↵Craig Topper2018-06-021-2/+2
| | | | | | | | the assembly parser. The caret was positioned on the wrong operand. It's too hard to get right so just put the caret at the beginning of the instruction. llvm-svn: 333821
* [InstCombine] call simplify before trying vector foldsSanjay Patel2018-06-027-152/+134
| | | | | | | | | | | | | | | | | | | | As noted in the review thread for rL333782, we could have made a bug harder to hit if we were simplifying instructions before trying other folds. The shuffle transform in question isn't ever a simplification; it's just a canonicalization. So I've renamed that to make that clearer. This is NFCI at this point, but I've regenerated the test file to show the cosmetic value naming difference of using instcombine's RAUW vs. the builder. Possible follow-ups: 1. Move reassociation folds after simplifies too. 2. Refactor common code; we shouldn't have so much repetition. llvm-svn: 333820
* [NEON] Support VLD1xN intrinsics in AArch32 mode (Clang part)Ivan A. Kosarev2018-06-027-7/+456
| | | | | | | | | We currently support them only in AArch64. The NEON Reference, however, says they are 'ARMv7, ARMv8' intrinsics. Differential Revision: https://reviews.llvm.org/D47121 llvm-svn: 333819
* [InstCombine] add more tests for shuffle-binop; NFCSanjay Patel2018-06-021-4/+315
| | | | | | | | As noted in the review thread for rL333782, we're lacking coverage for this transform, so add tests for each binop opcode with constant operand. llvm-svn: 333818
* [Support] Remove unused raw_ostream::handle whose anchor role was superseded ↵Fangrui Song2018-06-023-7/+1
| | | | | | by anchor() llvm-svn: 333817
* Fix silly error introduced after testing in r333813.James Y Knight2018-06-021-7/+0
| | | | | | Oops. llvm-svn: 333816
* Revert "This diff includes changes for supporting the following types."Leonard Chan2018-06-0238-450/+6
| | | | | | | This reverts commit r333814, which fails for a test checking the bit width on ubuntu. llvm-svn: 333815
* This diff includes changes for supporting the following types.Leonard Chan2018-06-0238-6/+450
| | | | | | | | | | | | | | | | | | | | | | | | | | | ``` // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; ``` This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches. The tests included are for asserting that we can declare these types. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333814
* Fix support for distinguishing archive members by timestamp on Darwin.James Y Knight2018-06-027-3/+136
| | | | | | | | | | | | | | | | | | | On Darwin, the binary's symbol table points to debug info in object files -- potentially object files within a static library. Such a library may have multiple entries with the same name, distinguished only by timestamp. The code was already _attempting_ to handle this case (see the code in ObjectContainerBSDArchive::Archive::FindObject which disambiguates via timestamp). But, unfortunately, while the timestamp was taken into account on the _first_ lookup, the result was then cached in a map keyed only off of the path. Added the timestamp to the cache, and added a test case. Differential Revision: https://reviews.llvm.org/D47660 llvm-svn: 333813
* [X86] Add encoding information for the AVX5124FMAPS and AVX5124VNNIW ↵Craig Topper2018-06-023-1/+78
| | | | | | | | | | instructions so they can be assembled and disassembled. These instructions are unusual in that they operate on 4 consecutive registers so supporting them in codegen will be more difficult than normal. Includes an assembler check to warn if the source register is not the first register of a 4 register group. llvm-svn: 333812
* [PM/LoopUnswitch] Fix how the cloned loops are handled when updating analyses.Chandler Carruth2018-06-022-44/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I noticed this issue because we didn't put the primary cloned loop into the `NonChildClonedLoops` vector and so never iterated on it. Once I fixed that, it made it clear why I had to do a really complicated and unnecesasry dance when updating the loops to remain in canonical form -- I was unwittingly working around the fact that the primary cloned loop wasn't in the expected list of cloned loops. Doh! Now that we include it in this vector, we don't need to return it and we can consolidate the update logic as we correctly have a single place where it can be handled. I've just added a test for the iteration order aspect as every time I changed the update logic partially or incorrectly here, an existing test failed and caught it so that seems well covered (which is also evidenced by the extensive working around of this missing update). Reviewers: asbirlea, sanjoy Subscribers: mcrosier, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D47647 llvm-svn: 333811
* [cmake] Support LLD for CLANG_ORDER_FILEShoaib Meenai2018-06-021-2/+5
| | | | | | | | | | | | | | | | | LLD also supports order files using the `--symbol-ordering-file` option. As the name would suggest, the order file format is slightly different from gold; gold's order files specify section names, whereas LLD's specify symbol names. Assuming you have an order file in the correct format though, we should support using it with LLD. Switch the check to actually use LLVM's linker detection rather than just checking for the presence of the gold executable, since we might have a gold executable present but be using LLD (or bfd for that matter) as our linker. Differential Revision: https://reviews.llvm.org/D47669 llvm-svn: 333810
* [Fuzzer] Migrate Fuchsia port from launchpad to fdio_spawnPetr Hosek2018-06-021-19/+36
| | | | | | | | fdio_spawn is the new public API for launching processes in Fuchsia. Differential Revision: https://reviews.llvm.org/D47649 llvm-svn: 333809
* [cmake] Use LLVM's check_linker_flagShoaib Meenai2018-06-021-8/+1
| | | | | | | LLVM already defines this function, so make use of it instead of rolling our own. llvm-svn: 333808
* Remove the test from r333801Vedant Kumar2018-06-021-21/+0
| | | | | | | | | | | | In r333801 I added a test for a dump method that, for reasons I don't understand, fails on an msvc bot: http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/12306/ I'll remove the test for now to unblock the bot and try to look into why there's a discrepancy on this platform later. llvm-svn: 333807
* [DebugInfo] Refactoring DIType::setFlags to DIType::cloneWithFlags, NFCRoman Tereshin2018-06-016-23/+92
| | | | | | | | | | | | | | | | | | and using the latter in DIBuilder::createArtificialType and DIBuilder::createObjectPointerType methods as well as introducing mirroring DISubprogram::cloneWithFlags and DIBuilder::createArtificialSubprogram methods. The primary goal here is to add createArtificialSubprogram to support a pass downstream while keeping the method consistent with the existing ones and making sure we don't encourage changing already created DI-nodes. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D47615 llvm-svn: 333806
* Revert "Re-land: [MachO] Fixing ub in MachO BinaryFormat"Chris Bieneman2018-06-013-51/+1
| | | | | | | | This reverts commit r333803. Still breaking on big endian. Will sort this out later. llvm-svn: 333805
* [X86] Do something sensible when an expand load intrinsic is passed a 0 mask.Craig Topper2018-06-012-1/+10
| | | | | | Previously we just returned undef, but really we should be returning the pass thru input. We also need to make sure we preserve the chain output that the original intrinsic node had to maintain connectivity in the DAG. So we should just return the incoming chain as the output chain. llvm-svn: 333804
* Re-land: [MachO] Fixing ub in MachO BinaryFormatChris Bieneman2018-06-013-1/+51
| | | | | | | | | | | | | | This re-lands r333797 with a fix for big endian systems. Original commit message: This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed. The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned. There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232. llvm-svn: 333803
* Add Features.def to module mapEric Fiselier2018-06-011-0/+1
| | | | llvm-svn: 333802
* Add a debug dump for DbgValueHistoryMapVedant Kumar2018-06-014-0/+58
| | | | | | | | | This makes it easier to inspect the results of DbgValueHistoryCalculator. Differential Revision: https://reviews.llvm.org/D47663 llvm-svn: 333801
* [X86] Add isel patterns to use vexpand with zero masking when the passthru ↵Craig Topper2018-06-017-60/+34
| | | | | | value is a zero vector. llvm-svn: 333800
* Revert "[MachO] Fixing ub in MachO BinaryFormat"Chris Bieneman2018-06-013-47/+1
| | | | | | | | | | This reverts commit r333797. This patch is failing on BigEndian bots. I will fix and re-land: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/19505/ llvm-svn: 333799
* Move some function declarations out of WindowsSupport.hZachary Turner2018-06-018-14/+24
| | | | | | | | | | | | | | | | | | The idea behind WindowsSupport.h is that it's in the source directory so that windows.h'isms don't leak out into the larger LLVM project. To that end, any symbol that references a symbol from windows.h must be in this private header, and not in a public header. However, we had some useful utility functions in WindowsSupport.h which have no dependency on the Windows API, but still only make sense on Windows. Those functions should be usable outside of Support since there is no risk of causing a windows.h leak. Although this introduces some preprocessor logic in some header files, It's not too egregious and it's better than the alternative of duplicating a ton of code. Differential Revision: https://reviews.llvm.org/D47662 llvm-svn: 333798
* [MachO] Fixing ub in MachO BinaryFormatChris Bieneman2018-06-013-1/+47
| | | | | | | | | | This isn't encountered anywhere inside LLVM, so I wrote a test case to expose the issue and verify that it is fixed. The basic problem is that the macho_load_command union contains all load comamnd structs. Load command structs in 32-bit macho files can be 32-bit aligned instead of 64-bit aligned. There are some strange circumstances in which this can be exposed in a 64-bit macho if the load commands are invalid or if a 32-bit aligned load command is used. In the past we've worked around this type of problem with changes like r264232. llvm-svn: 333797
* Add weak definitions of trace-cmp hooks to dfsanKostya Serebryany2018-06-013-1/+75
| | | | | | | | | | | | | | | | | | | | | Summary: This allows to build and link the code with e.g. -fsanitize=dataflow -fsanitize-coverage=trace-pc-guard,pc-table,func,trace-cmp w/o providing (all) the definitions of trace-cmp hooks. This is similar to dummy hooks provided by asan/ubsan/msan for the same purpose, except that some of the hooks need to have the __dfsw_ prefix since we need dfsan to replace them. Reviewers: pcc Reviewed By: pcc Subscribers: delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D47605 llvm-svn: 333796
* [X86] Expand the testing of expand and compress intrinsicsCraig Topper2018-06-014-266/+1794
| | | | | | | | The avx512f intrinsic tests were in the avx512vl file. We were also missing some combinations of masking. This does show that we fail to use the zero masking form of expand loads when the passthru is zero. I'll try to get that fixed shortly. llvm-svn: 333795
* [X86] Add fast-isel tests for avx512vbmi2 instructions.Craig Topper2018-06-013-1/+2862
| | | | llvm-svn: 333794
* ELF: Ignore argument after --plugin.Peter Collingbourne2018-06-012-1/+3
| | | | | | | | | | | | | | Clang passes --plugin /path/to/LLVMgold.so to the linker when -flto is passed. After r333607 we only ignore --plugin as a joined argument, which means that the following argument (/path/to/LLVMgold.so) is interpreted as an input file. This means that either every LTO'd program ends up being linked with the gold plugin or we error out if the plugin does not exist. The fix is to use Eq to ignore both --plugin=foo and --plugin foo as before. Differential Revision: https://reviews.llvm.org/D47657 llvm-svn: 333793
* Show choices of multiple-choice options in `ld.lld --help` message.Rui Ueyama2018-06-011-13/+17
| | | | | | Differential Revision: https://reviews.llvm.org/D47656 llvm-svn: 333792
* Cap "voluntary" vector alignment at 16 for all Darwin platforms.John McCall2018-06-018-97/+123
| | | | | | | | | | | | | | | | | | | | | This fixes two major problems: - We were not capping vector alignment as desired on 32-bit ARM. - We were using different alignments based on the AVX settings on Intel, so we did not have a consistent ABI. This is an ABI break, but we think we can get away with it because vectors tend to be used mostly in inline code (which is why not having a consistent ABI has not proven disastrous on Intel). Intel's AVX types are specified as having 32-byte / 64-byte alignment, so align them explicitly instead of relying on the base ABI rule. Note that this sort of attribute is stripped from template arguments in template substitution, so there's a possibility that code templated over vectors will produce inadequately-aligned objects. The right long-term solution for this is for alignment attributes to be interpreted as true qualifiers and thus preserved in the canonical type. llvm-svn: 333791
* [lit, pdb] Fix two failing PDB tests on WindowsStella Stamenova2018-06-012-8/+8
| | | | | | | | | | | | | | Summary: One of the tests is failing to build because it needs GS-, the second test does not correctly match all the expected function names because newer DIA SDKs annotate the function names with their return type and inputs (e.g. "static long `anonymous namespace'::StaticFunction(int)") Reviewers: asmith, zturner Reviewed By: zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47653 llvm-svn: 333790
* [lit, lldbmi] Skip the new break-insert test on WindowsStella Stamenova2018-06-011-0/+4
| | | | | | | | | | | | | | Summary: Skip the new break-insert test on Windows because it hangs and so the test suite never completes. All other lldb-mi tests in the test suite are also skipped on windows Reviewers: asmith, aprantl, polyakov.alex Reviewed By: aprantl Subscribers: ki.stfu, llvm-commits Differential Revision: https://reviews.llvm.org/D47651 llvm-svn: 333789
* [asan, myriad] Implement aligned local pool allocationWalter Lee2018-06-011-1/+25
| | | | | | | | Extend the local pool allocation support to posix_memalign. Differential Revision: https://reviews.llvm.org/D47642 llvm-svn: 333788
* XFAIL TestIRMemoryMap.test on WindowsVedant Kumar2018-06-011-1/+1
| | | | | | | | I've xfailed this test instead of skipping it by request (https://reviews.llvm.org/D47646). Bug: https://bugs.llvm.org/show_bug.cgi?id=37656 llvm-svn: 333787
* Fix Module::FindTypes to return the correct number of matches.Frederic Riss2018-06-016-0/+43
| | | | | | | | | | | | | | | | | | | | | | In r331719, I changed Module::FindTypes not to limit the amount of types returned by the Symbol provider, because we want all possible matches to be able to filter them. In one code path, the filtering was applied to the TypeList without changing the number of types that gets returned. This is turn could cause consumers to access beyond the end of the TypeList. This patch fixes this case and also adds an assertion to TypeList::GetTypeAtIndex to catch those obvious programming mistakes. Triggering the condition in which we performed the incorrect access was not easy. It happened a lot in mixed Swift/ObjectiveC code, but I was able to trigger it in pure Objective C++ although in a contrieved way. rdar://problem/40254997 llvm-svn: 333786
* Disable TestIRMemoryMap.test on WindowsVedant Kumar2018-06-011-0/+2
| | | | | | | It's been pointed out in https://reviews.llvm.org/D47646 that lldb-test fails to create a usable process on Windows when running this test. llvm-svn: 333785
* [asan, myriad] Configure platform interceptorsWalter Lee2018-06-012-5/+16
| | | | | | | | | | | Myriad only uses the platform interceptors for memory allocation routines. Configure them properly. Also add a missing guard around aligned alloc interceptor. Differential Revision: https://reviews.llvm.org/D47641 llvm-svn: 333784
* [ConstantFold] Disallow folding vector geps into bitcastsKarl-Johan Karlsson2018-06-013-7/+11
| | | | | | | | | | | | | | | | | | | Summary: Getelementptr returns a vector of pointers, instead of a single address, when one or more of its arguments is a vector. In such case it is not possible to simplify the expression by inserting a bitcast of operand(0) into the destination type, as it will create a bitcast between different sizes. Reviewers: majnemer, mkuper, mssimpso, spatel Reviewed By: spatel Subscribers: lebedev.ri, llvm-commits Differential Revision: https://reviews.llvm.org/D46379 llvm-svn: 333783
* [InstCombine] fix vector shuffle transform to replace undef elements (PR37648)Sanjay Patel2018-06-012-4/+20
| | | | | | | | | | | | | | This bug: https://bugs.llvm.org/show_bug.cgi?id=37648 ...was created with the enhancement to this transform with rL332479. The urem test shows the disaster potential: any undef divisor lane makes the whole op undef. The test diffs show that vector demanded elements turns some of the potential, but not all, unused binop operands back into undef already. llvm-svn: 333782
* [lldb, process] Fix occasional hang when launching a process in LLDBStella Stamenova2018-06-013-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Occasionally, when launching a process in lldb (especially on windows, but not limited to), lldb will hang before the process is launched and it will never recover. This happens because the timing of the processing of the state changes can be slightly different. The state changes that are issued are: 1) SetPublicState(eStateLaunching) 2) SetPrivateState(eStateLaunching) 3) SetPublicState(eStateStopped) 4) SetPrivateState(eStateStopped) What we expect to see is: public state: launching -> launching -> stopped private state: launching -> stopped What we see is: public state: launching -> stopped -> launching private state: launching -> stopped The second launching change to the public state is issued when WaitForProcessStopPrivate calls HandlePrivateEvent on the event which was created when the private state was set to launching. HandlePrivateEvent has logic to determine whether to broadcase the event and a launching event is *always* broadcast. At the same time, when the stopped event is processed by WaitForProcessStopPrivate next, the function exists and that event is never broadcast, so the public state remains as launching. HandlePrivateEvent does two things: determine whether there's a next action as well as determine whether to broadcast the event that was processed. There's only ever a next action set if we are trying to attach to a process, but WaitForProcessStopPrivate is only ever called when we are launching a process or connecting remotely, so the first part of HandlePrivateEvent (handling the next action) is irrelevant for WaitForProcessStopPrivate. As far as broadcasting the event is concerned, since we are handling state changes that already occurred to the public state (and are now duplicated in the private state), I believe the broadcast step is unnecessary also (and in fact, it causes the hang). This change removes the call to HandlePrivateEvent from inside WaitForProcessStopPrivate. Incidentally, there was also a bug filed recently that is the same issue: https://bugs.llvm.org/show_bug.cgi?id=37496 Reviewers: asmith, labath, zturner, jingham Reviewed By: zturner, jingham Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47609 llvm-svn: 333781
* partitionSetParts from C to C++ interface.Tobias Grosser2018-06-011-41/+32
| | | | | | | | | | | | | | | | Summary: partitionSetParts from C to new C++ interface. Reviewers: grosser, Meinersbur, jdoerfert, bollu, cs15btech11044 Reviewed By: grosser, Meinersbur Subscribers: llvm-commits, pollydev Tags: #polly Differential Revision: https://reviews.llvm.org/D47252 llvm-svn: 333780
* [InstCombine] add tests for broken shuffle transform (PR37648)Sanjay Patel2018-06-011-0/+23
| | | | llvm-svn: 333779
OpenPOWER on IntegriCloud