Commit Graph

290980 Commits

Author SHA1 Message Date
Simon Pilgrim 8790844848 [X86][SSE] Cleanup SSE2 intrinsics tests
Ensure we cover 32/64-bit targets for SSE/AVX/AVX512 cases as necessary

llvm-svn: 333832
2018-06-02 19:43:14 +00:00
Simon Pilgrim 8c5b33a085 [X86][SSE] Cleanup SSE3/SSSE3 intrinsics tests
Ensure we cover 32/64-bit targets for SSE/AVX/AVX512 cases as necessary

llvm-svn: 333831
2018-06-02 18:41:46 +00:00
Simon Pilgrim 1c0fa05397 [X86][SSE4] Tweak rL333828 sse41/sse42 cleanup to recover SKX/EVEX2VEX testing
Just testing for avx512f was missing the tests for EVEX TO VEX Compression encoding etc.

llvm-svn: 333830
2018-06-02 18:01:09 +00:00
Ivan A. Kosarev 9c40c0ad0c [NEON] Support VLD1xN intrinsics in AArch32 mode (Clang part)
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: 333829
2018-06-02 17:42:59 +00:00
Simon Pilgrim dda8daec73 [X86][SSE] Cleanup SSE4A/SSE41/SSE42 intrinsics tests
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
2018-06-02 17:33:26 +00:00
Simon Pilgrim d93157c1b3 [X86][BMI2] Test i32 intrinsics on 32/64 bits + branch off i64 tests
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
2018-06-02 17:22:13 +00:00
Simon Pilgrim 6028dc451a [X86][BMI1] Remove test for non-existent andn i16 instruction
llvm-svn: 333826
2018-06-02 17:02:27 +00:00
Ivan A. Kosarev 60a991ed1a [NEON] Support VLD1xN intrinsics in AArch32 mode (LLVM part)
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
2018-06-02 16:40:03 +00:00
Ivan A. Kosarev 73c5337a64 Revert r333819 "[NEON] Support VLD1xN intrinsics in AArch32 mode (Clang part)"
The LLVM part was committed instead of the Clang part.

Differential Revision: https://reviews.llvm.org/D47121

llvm-svn: 333824
2018-06-02 16:38:38 +00:00
Michael J. Spencer ae6eeaea92 [MC] Add assembler support for .cg_profile.
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
2018-06-02 16:33:01 +00:00
Craig Topper 93d8fbd8f2 [X86] Add tied source operand to AVX5124FMAPS and AVX5124VNNIW instructions.
This doesn't affect the assembly or disassembly, but is more accurate.

llvm-svn: 333822
2018-06-02 16:30:39 +00:00
Craig Topper 27234f1d8f [X86] Fix warning message for AVX5124FMAPS and AVX5124VNNIW instructions in 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
2018-06-02 16:30:36 +00:00
Sanjay Patel bbc6d60677 [InstCombine] call simplify before trying vector folds
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
2018-06-02 16:27:44 +00:00
Ivan A. Kosarev 51f19b9ee1 [NEON] Support VLD1xN intrinsics in AArch32 mode (Clang part)
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
2018-06-02 16:26:42 +00:00
Sanjay Patel b6333486f4 [InstCombine] add more tests for shuffle-binop; NFC
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
2018-06-02 16:16:42 +00:00
Fangrui Song 8ca769d204 [Support] Remove unused raw_ostream::handle whose anchor role was superseded by anchor()
llvm-svn: 333817
2018-06-02 06:00:35 +00:00
James Y Knight 7177528783 Fix silly error introduced after testing in r333813.
Oops.

llvm-svn: 333816
2018-06-02 04:00:16 +00:00
Leonard Chan 0d485dbb40 Revert "This diff includes changes for supporting the following types."
This reverts commit r333814, which fails for a test checking the bit
width on ubuntu.

llvm-svn: 333815
2018-06-02 03:27:13 +00:00
Leonard Chan db55d8331e This diff includes changes for supporting the following types.
```

// 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
2018-06-02 02:58:51 +00:00
James Y Knight 9c2d52014c Fix support for distinguishing archive members by timestamp on Darwin.
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
2018-06-02 02:44:10 +00:00
Craig Topper 1534929623 [X86] Add encoding information for the AVX5124FMAPS and AVX5124VNNIW 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
2018-06-02 02:15:10 +00:00
Chandler Carruth 9281503e8f [PM/LoopUnswitch] Fix how the cloned loops are handled when updating analyses.
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
2018-06-02 01:29:01 +00:00
Shoaib Meenai db5781a78f [cmake] Support LLD for CLANG_ORDER_FILE
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
2018-06-02 01:22:39 +00:00
Petr Hosek 8908aa4e30 [Fuzzer] Migrate Fuchsia port from launchpad to fdio_spawn
fdio_spawn is the new public API for launching processes in Fuchsia.

Differential Revision: https://reviews.llvm.org/D47649

llvm-svn: 333809
2018-06-02 01:17:10 +00:00
Shoaib Meenai 9c0d10ab6b [cmake] Use LLVM's check_linker_flag
LLVM already defines this function, so make use of it instead of rolling
our own.

llvm-svn: 333808
2018-06-02 00:49:54 +00:00
Vedant Kumar 4a2798c934 Remove the test from r333801
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
2018-06-02 00:05:17 +00:00
Roman Tereshin cf88ffaaf9 [DebugInfo] Refactoring DIType::setFlags to DIType::cloneWithFlags, NFC
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
2018-06-01 23:15:09 +00:00
Chris Bieneman 4b3701a7a7 Revert "Re-land: [MachO] Fixing ub in MachO BinaryFormat"
This reverts commit r333803.

Still breaking on big endian. Will sort this out later.

llvm-svn: 333805
2018-06-01 23:09:37 +00:00
Craig Topper 3828ce7eab [X86] Do something sensible when an expand load intrinsic is passed a 0 mask.
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
2018-06-01 22:59:07 +00:00
Chris Bieneman 44e272d440 Re-land: [MachO] Fixing ub in MachO BinaryFormat
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
2018-06-01 22:52:59 +00:00
Eric Fiselier 157af1ad74 Add Features.def to module map
llvm-svn: 333802
2018-06-01 22:51:59 +00:00
Vedant Kumar 7224c08141 Add a debug dump for DbgValueHistoryMap
This makes it easier to inspect the results of
DbgValueHistoryCalculator.

Differential Revision: https://reviews.llvm.org/D47663

llvm-svn: 333801
2018-06-01 22:33:15 +00:00
Craig Topper aa747412b1 [X86] Add isel patterns to use vexpand with zero masking when the passthru value is a zero vector.
llvm-svn: 333800
2018-06-01 22:28:28 +00:00
Chris Bieneman 52b2cc5dab Revert "[MachO] Fixing ub in MachO BinaryFormat"
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
2018-06-01 22:28:23 +00:00
Zachary Turner b44d7a0da1 Move some function declarations out of WindowsSupport.h
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
2018-06-01 22:23:46 +00:00
Chris Bieneman c8a3c86c77 [MachO] Fixing ub in MachO BinaryFormat
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
2018-06-01 22:07:36 +00:00
Kostya Serebryany d74d04a6c5 Add weak definitions of trace-cmp hooks to dfsan
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
2018-06-01 21:59:25 +00:00
Craig Topper c45479c08e [X86] Expand the testing of expand and compress intrinsics
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
2018-06-01 21:59:24 +00:00
Craig Topper d7e11ee342 [X86] Add fast-isel tests for avx512vbmi2 instructions.
llvm-svn: 333794
2018-06-01 21:59:22 +00:00
Peter Collingbourne 7234acf5bb ELF: Ignore argument after --plugin.
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
2018-06-01 21:51:21 +00:00
Rui Ueyama 92675dff00 Show choices of multiple-choice options in `ld.lld --help` message.
Differential Revision: https://reviews.llvm.org/D47656

llvm-svn: 333792
2018-06-01 21:46:10 +00:00
John McCall 280c656031 Cap "voluntary" vector alignment at 16 for all Darwin platforms.
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
2018-06-01 21:34:26 +00:00
Stella Stamenova b8d861c27a [lit, pdb] Fix two failing PDB tests on Windows
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
2018-06-01 21:33:27 +00:00
Stella Stamenova 1263949d40 [lit, lldbmi] Skip the new break-insert test on Windows
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
2018-06-01 21:29:43 +00:00
Walter Lee e2f884d73f [asan, myriad] Implement aligned local pool allocation
Extend the local pool allocation support to posix_memalign.

Differential Revision: https://reviews.llvm.org/D47642

llvm-svn: 333788
2018-06-01 21:29:05 +00:00
Vedant Kumar 350214674b XFAIL TestIRMemoryMap.test on Windows
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
2018-06-01 20:32:32 +00:00
Frederic Riss 9cd4def1c6 Fix Module::FindTypes to return the correct number of matches.
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
2018-06-01 20:14:21 +00:00
Vedant Kumar 1943b49c99 Disable TestIRMemoryMap.test on Windows
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
2018-06-01 20:02:57 +00:00
Walter Lee bf03bfb0a3 [asan, myriad] Configure platform interceptors
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
2018-06-01 19:47:41 +00:00
Karl-Johan Karlsson 6d52e5c3e4 [ConstantFold] Disallow folding vector geps into bitcasts
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
2018-06-01 19:34:35 +00:00