Fixed issue with microMIPS long branch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195975 91177308-0d34-0410-b5e6-96231b3b80d8
Test case for issue with microMIPS long branch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195976 91177308-0d34-0410-b5e6-96231b3b80d8
Update the cpu specified on some PPC regression tests

Some of these tests did not specify a cpu but were also sensitive to
instruction scheduling and/or register assignment choices. A few others
similarly-sensitive tests specified a cpu (often the POWER7), and while the P7
currently uses the default model for PPC64, this will soon change. For those
tests which should not really be cpu-dependent anyway, the cpu is set to the
generic 'ppc64'.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195977 91177308-0d34-0410-b5e6-96231b3b80d8
Desensitize a couple of PPC regression tests

Use CHECK-DAG to make these regression tests more resilient against changes in
instruction scheduling.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195978 91177308-0d34-0410-b5e6-96231b3b80d8
Convert a PPC test from grep to FileCheck

Convert this test to FileCheck, and improve it to check for the instructions it
is trying to exclude instead of checking for register use (especially because
grepping for r1 can be thrown off, for example, by a use of r12).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195979 91177308-0d34-0410-b5e6-96231b3b80d8
Split some PPC itinerary classes

In preparation for adding scheduling definitions for the POWER7, split some PPC
itinerary classes so that the P7's latencies and hazards can be better
described. For the most part, this means differentiating indexed from non-index
pre-increment loads and stores. Also, differentiate single from
double-precision sqrt.

No functionality change intended (except for a more-specific latency for
single-precision sqrt on the A2).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195980 91177308-0d34-0410-b5e6-96231b3b80d8
Add a scheduling model (with itinerary) for the PPC POWER7

This adds a scheduling model for the POWER7 (P7) core, and enables the
machine-instruction scheduler when targeting the P7. Scheduling for the P7,
like earlier ooo PPC cores, requires considering both dispatch group hazards,
and functional unit resources and latencies. These are both modeled in a
combined itinerary. Dispatch group formation is still handled by the post-RA
scheduler (which still needs to be updated for the P7, but nevertheless does a
pretty good job).

One interesting aspect of this change is that I've also enabled to use of AA
duing CodeGen for the P7 (just as it is for the embedded cores). The benchmark
results seem to support this decision (see below), and while this is normally
useful for in-order cores, and not for ooo cores like the P7, I think that the
dispatch slot hazards are enough like in-order resources to make the AA useful.

Test suite significant performance differences (where negative is a speedup,
and positive is a regression) vs. the current situation:

MultiSource/Benchmarks/BitBench/drop3/drop3
  with AA: N/A
  without AA: -28.7614% +/- 19.8356%
(significantly against AA)

MultiSource/Benchmarks/FreeBench/neural/neural
  with AA: -17.7406% +/- 11.2712%
  without AA: N/A
(significantly in favor of AA)

MultiSource/Benchmarks/SciMark2-C/scimark2
  with AA: -11.2079% +/- 1.80543%
  without AA: -11.3263% +/- 2.79651%

MultiSource/Benchmarks/TSVC/Symbolics-flt/Symbolics-flt
  with AA: -41.8649% +/- 17.0053%
  without AA: -34.5256% +/- 23.7072%

MultiSource/Benchmarks/mafft/pairlocalalign
  with AA: 25.3016% +/- 17.8614%
  without AA: 38.6629% +/- 14.9391%
(significantly in favor of AA)

MultiSource/Benchmarks/sim/sim
  with AA: N/A
  without AA: 13.4844% +/- 7.18195%
(significantly in favor of AA)

SingleSource/Benchmarks/BenchmarkGame/Large/fasta
  with AA: 15.0664% +/- 6.70216%
  without AA: 12.7747% +/- 8.43043%

SingleSource/Benchmarks/BenchmarkGame/puzzle
  with AA: 82.2713% +/- 26.3567%
  without AA: 75.7525% +/- 41.1842%

SingleSource/Benchmarks/Misc/flops-2
  with AA: -37.1621% +/- 20.7964%
  without AA: -35.2342% +/- 20.2999%
(significantly in favor of AA)

These are 99.5% confidence intervals from 5 runs per configuration. Regarding
the choice to turn on AA during CodeGen, of these results, four seem
significantly in favor of using AA, and one seems significantly against. I'm
not making this decision based on these numbers alone, but these results
seem consistent with results I have from other tests, and so I think that, on
balance, using AA is a win.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195981 91177308-0d34-0410-b5e6-96231b3b80d8
Use 'unsigned char' to get this past gcc error message:

  error: invalid conversion from 'unsigned char' to '{anonymous}::Sequence'

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196004 91177308-0d34-0410-b5e6-96231b3b80d8
Use accessor methods instead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196006 91177308-0d34-0410-b5e6-96231b3b80d8
Ensure bitcode encoding of linkage types stays stable. Patch by Boaz Ouriel

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196042 91177308-0d34-0410-b5e6-96231b3b80d8
Revamp error checking in the ms inline asm parser.

- Actually abort when an error occurred.
- Check that the frontend lookup worked when parsing length/size/type operators.

Tested by a clang test. PR18096.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196044 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: fix bug in -Oz stack adjustment folding

Previously, we clobbered callee-saved registers when folding an "add
sp, #N" into a "pop {rD, ...}" instruction. This change checks whether
a register we're going to add to the "pop" could actually be live
outside the function before doing so and should fix the issue.

This should fix PR18081.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196046 91177308-0d34-0410-b5e6-96231b3b80d8
Add -mcpu to stackmap.ll

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196051 91177308-0d34-0410-b5e6-96231b3b80d8
Also test the created stubs on 32 bits.

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