Commit Graph

291299 Commits

Author SHA1 Message Date
Craig Topper f886b44693 [X86] Pass ArrayRef instead of SmallVectorImpl& to the X86 builtin helper functions. NFC
llvm-svn: 333851
2018-06-03 19:02:57 +00:00
Craig Topper 8508c1db98 Revert r333848 "[X86] Pass ArrayRef instead of SmallVectorImpl& to the X86 builtin helper functions. NFC"
Looks like I missed some changes to make this work.

llvm-svn: 333850
2018-06-03 18:41:22 +00:00
Simon Pilgrim 7c4446ce0c [X86][TBM] Use realistic BEXTR control bits
Avoid constant values that are guaranteed to give zero

Found while investigating BEXTR optimizations for PR34042.

llvm-svn: 333849
2018-06-03 18:15:06 +00:00
Craig Topper d4a610f6f7 [X86] Pass ArrayRef instead of SmallVectorImpl& to the X86 builtin helper functions. NFC
llvm-svn: 333848
2018-06-03 18:08:37 +00:00
Craig Topper 21f56f5b9c [X86] When emitting masked loads/stores don't check for all ones mask.
This seems like a premature optimization. It's unlikely a user would pass something the frontend can tell is all ones to the masked load/store intrinsics.

We do this optimization for emitting select for masking because we have builtin calls in header files that pass an all ones mask in. Though at this point we may not longer have any builtins that emit some IR and a select. We may only have the select builtins so maybe we can remove that optimization too.

llvm-svn: 333847
2018-06-03 18:08:36 +00:00
Craig Topper 10229af755 [X86] Mark the pointer arguments to expandload builtins as const consistently.
Some of them had it and some didn't. This should make them consistent.

llvm-svn: 333846
2018-06-03 18:08:34 +00:00
Sanjay Patel 3bd957b7ae [InstCombine] improve sub with bool folds
There's a patchwork of existing transforms trying to handle
these cases, but as seen in the changed test, we weren't
catching them all.

llvm-svn: 333845
2018-06-03 16:35:26 +00:00
Alexander Polyakov cc92f5038e [lldb, lldm-mi] Fix hanging of -exec-run command.
Summary: -exec-run command hanged in case of invalid or dummy target.

Reviewers: aprantl, stella.stamenova

Reviewed By: aprantl

Subscribers: ki.stfu, llvm-commits, lldb-commits

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

llvm-svn: 333844
2018-06-03 15:15:23 +00:00
Simon Pilgrim 1f60e2b41b [X86][AVX512] Cleanup intrinsics tests
Ensure we test on 32-bit and 64-bit targets, and strip -mcpu usage.

Part of ongoing work to ensure we test all intrinsic style tests on 32 and 64 bit targets where possible.

llvm-svn: 333843
2018-06-03 14:56:04 +00:00
Simon Pilgrim 7d717fed0b [X86][AVX512BW] Regenerate arithmetic tests using update_llc_test_checks.py script
Require manual stripping of existing CHECKs as update_llc_test_checks doesn't remove them if they're outside the function

llvm-svn: 333842
2018-06-03 14:31:30 +00:00
Simon Pilgrim e370ade180 [X86][BMI1] Test i32 intrinsics on 32/64 bits + branch off i64 tests
Further refactoring will wait until D47452 has landed.

Part of ongoing work to ensure we test all intrinsic style tests on 32 and 64 bit targets where possible.

llvm-svn: 333841
2018-06-03 14:11:34 +00:00
Simon Pilgrim 8dc43621ec [X86][BMI] Remove CTTZ tests - this is fully covered in clz.ll
llvm-svn: 333840
2018-06-03 13:55:17 +00:00
Simon Pilgrim d4ef869e28 [X86][TBM] Branch off i32 intrinsics and test on 32/64 bits
Part of ongoing work to ensure we test all intrinsic style tests on 32 and 64 bit targets where possible.

llvm-svn: 333839
2018-06-03 13:38:52 +00:00
Amaury Sechet 99909e9308 Remove SETCCE use from Lanai's backend
Summary: This creates a small perf regression, but after talking with Jacques Pienaar, he was good with it to get things moving toward removng SETCCE.

Reviewers: jpienaar, bryant

Subscribers: llvm-commits

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

llvm-svn: 333838
2018-06-03 12:56:24 +00:00
Alexander Polyakov 2c5a424150 Test commit. Fix typo in comment.
llvm-svn: 333837
2018-06-03 12:41:00 +00:00
Fangrui Song 75ae73f346 clang-interpreter: Add missing LLVM component Object
llvm-svn: 333836
2018-06-03 08:12:15 +00:00
Lang Hames 353499fc95 [ORC] Use JITEvaluatedSymbol for IndirectStubsManager findStub and findPointer.
Existing implementations of these methods do not require lazy materialization,
and switching to JITEvaluatedSymbol allows us to remove error checking on the
client side.

llvm-svn: 333835
2018-06-03 02:18:03 +00:00
Simon Pilgrim 2b55e751ce [X86][SSE] Cleanup AVX1 intrinsics tests
Ensure we cover 32/64-bit targets for SSE/AVX/AVX512 cases as necessary, strip -mcpu usage.

llvm-svn: 333834
2018-06-02 21:35:48 +00:00
Simon Pilgrim 58ff2ecc4b [X86][SSE] Cleanup SSE1 intrinsics tests
Ensure we cover 32/64-bit targets for SSE/AVX/AVX512 cases as necessary

llvm-svn: 333833
2018-06-02 20:25:56 +00:00
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