DebugInfo: Move the reference to the CU from the location list entry to the list itself, since it is constant across an entire list.

This simplifies construction and usage while making the data structure
smaller. It was a holdover from the days when we didn't have a separate
DebugLocList and all we had was a flat list of DebugLocEntries.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214933 91177308-0d34-0410-b5e6-96231b3b80d8
Fix typos in comments and doc

Committing http://reviews.llvm.org/D4798 for Robin Morisset (morisset@google.com)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214934 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Add definitions for ds_read2st64_ / ds_write2st64_

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214936 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Fix a bunch of tests that, owing to their compile_unit metadata not including a 13th field, had some subtle behavior.

Without the 13th field, the "emission kind" field defaults to 0 (which
is not equal to either of the values of the emission kind enum (1 ==
full debug info, 2 == line tables only)).

In this particular instance, the comparison with "FullDebugInfo" was
done when adding elements to the ranges list - so for these test cases
no values were added to the ranges list.

This got weirder when emitting debug_loc entries as the addresses should
be relative to the range of the CU if the CU has only one range (the
reasonable assumption is that if we're emitting debug_loc lists for a CU
that CU has at least one range - but due to the above situation, it has
zero) so the ranges were emitted relative to the start of the section
rather than relative to the start of the CU's singular range.

Fix these tests by accounting for the difference in the description of
debug_loc entries (in some cases making the test ignorant to these
differences, in others adding the extra label difference expression,
etc) or the presence/absence of high/low_pc on the CU, and add the 13th
field to their CUs to enable proper "full debug info" emission here.

In a future commit I'll fix up a bunch of other test cases that are not
so rigorously depending on this behavior, but still doing similarly
weird things due to the missing 13th field.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214937 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Assert that any CU for which debug_loc lists are emitted, has at least one range.

This was coming in weird debug info that had variables (and hence
debug_locs) but was in GMLT mode (because it was missing the 13th field
of the compile_unit metadata) so no ranges were constructed. We should
always have at least one range for any CU with a debug_loc in it -
because the range should cover the debug_loc.

The assertion just ensures that the "!= 1" range case inside the
subsequent loop doesn't get entered for the case where there are no
ranges at all, which should never reach here in the first place.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214939 91177308-0d34-0410-b5e6-96231b3b80d8
[X86][SchedModel] Fixed some wrong scheduling model found by code inspection.
Source: Agner Fog's Instruction tables.

Related to <rdar://problem/15607571>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214940 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Implement areLoadsFromSameBasePtr

This currently has a noticable effect on the kernel argument loads.
LDS and global loads are more problematic, I think because of how copies
are currently inserted to ensure that the address is a VGPR.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214942 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Increase nearby load scheduling threshold.

This partially fixes weird looking load scheduling
in memcpy test. The load clustering doesn't seem
particularly smart, but this method seems to be partially
deprecated so it might not be worth trying to fix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214943 91177308-0d34-0410-b5e6-96231b3b80d8
[dfsan] Try not to create too many additional basic blocks in functions which
already have a large number of blocks. Works around a performance issue with
the greedy register allocator.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214944 91177308-0d34-0410-b5e6-96231b3b80d8
Correct comment

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214945 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Fixes commit r214890 to match the posted patch

This was another fallout from my local rebase where something went wrong :(

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214951 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Switch to a formulation of a for loop that is much more obviously
not corrupting the mask by mutating it more times than intended. No
functionality changed (the results were non-overlapping so the old
version "worked" but was non-obvious).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214953 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Fix two independent miscompiles in the process of getting the same
test case to actually generate correct code.

The primary miscompile fixed here is that we weren't correctly handling
in-place elements in one half of a single-input v8i16 shuffle when
moving a dword of elements from that half to the other half. Some times,
we would clobber the in-place elements in forming the dword to move
across halves.

The fix to this involves forcibly marking the in-place inputs even when
there is no need to gather them into a dword, and to much more carefully
re-arrange the elements when grouping them into a dword to move across
halves. With these two changes we would generate correct shuffles for
the test case, but found another miscompile. There are also some random
perturbations of the generated shuffle pattern in SSE2. It looks like
a wash; more instructions in some cases fewer in others.

The second miscompile would corrupt the results into nonsense. This is
a buggy pattern in one of the added DAG combines. Mapping elements
through a PSHUFD when pairing redundant half-shuffles is *much* harder
than this code makes it out to be -- it requires reasoning about *all*
of where the input is used in the PSHUFD, not just one part of where it
is used. Plus, we can't combine a half shuffle *into* a PSHUFD but the
code didn't guard against it. I think this was just a bad idea and I've
just removed that aspect of the combine. No tests regress as
a consequence so seems OK.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214954 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Conditional selects are expensive on out-of-order cores.

Specifically Cortex-A57. This probably applies to Cyclone too but I haven't enabled it for that as I can't test it.

This gives ~4% improvement on SPEC 174.vpr, and ~1% in 471.omnetpp.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214957 91177308-0d34-0410-b5e6-96231b3b80d8
ARM-MachO: materialize callee address correctly on v4t.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214958 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: do not generate BLX instructions on Cortex-M CPUs.

Particularly on MachO, we were generating "blx _dest" instructions on M-class
CPUs, which don't actually exist. They happen to get fixed up by the linker
into valid "bl _dest" instructions (which is why such a massive issue has
remained largely undetected), but we shouldn't rely on that.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214959 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new option -run-slp-after-loop-vectorization.

This swaps the order of the loop vectorizer and the SLP/BB vectorizers. It is disabled by default so we can do performance testing - ideally we want to change to having the loop vectorizer running first, and the SLP vectorizer using its leftovers instead of the other way around.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214963 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Add a testcase for r214957.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214965 91177308-0d34-0410-b5e6-96231b3b80d8
[AVX512] Added load/store instructions to Register2Memory opcode tables.
Added lowering tests for load/store.

Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214972 91177308-0d34-0410-b5e6-96231b3b80d8
use register iterators that include self to reduce code duplication in CriticalAntiDepBreaker

This patch addresses 2 FIXME comments that I added to CriticalAntiDepBreaker while fixing PR20020.

Initialize an MCSubRegIterator and an MCRegAliasIterator to include the self reg.

Assuming that works as advertised, there should be functional difference with this patch, just less code.

Also, remove the associated asserts - we're setting those values just before, so the asserts don't do anything meaningful.

Differential Revision: http://reviews.llvm.org/D4566



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214973 91177308-0d34-0410-b5e6-96231b3b80d8