Fix register pressure tables on ARM.

The heuristic that merges register pressure sets was bogus for ARM's S/D regs.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187479 91177308-0d34-0410-b5e6-96231b3b80d8
Add parentheses to silence gcc warning.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187482 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Add RISBLG and RISBHG instruction definitions

The next patch will make use of RISBLG for codegen.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187490 91177308-0d34-0410-b5e6-96231b3b80d8
Added INSERT and EXTRACT intructions from AVX-512 ISA.
All insertf*/extractf* functions replaced with insert/extract since we have insertf and inserti forms.
Added lowering for INSERT_VECTOR_ELT / EXTRACT_VECTOR_ELT for 512-bit vectors.
Added lowering for EXTRACT/INSERT subvector for 512-bit vectors.
Added a test.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187491 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Postpone NI->RISBG conversion to convertToThreeAddress()

r186399 aggressively used the RISBG instruction for immediate ANDs,
both because it can handle some values that AND IMMEDIATE can't,
and because it allows the destination register to be different from
the source.  I realized later while implementing the distinct-ops
support that it would be better to leave the choice up to
convertToThreeAddress() instead.  The AND IMMEDIATE form is shorter
and is less likely to be cracked.

This is a problem for 32-bit ANDs because we assume that all 32-bit
operations will leave the high word untouched, whereas RISBG used in
this way will either clear the high word or copy it from the source
register.  The patch uses the z196 instruction RISBLG for this instead.

This means that z10 will be restricted to NILL, NILH and NILF for
32-bit ANDs, but I think that should be OK for now.  Although we're
using z10 as the base architecture, the optimization work is going
to be focused more on z196 and zEC12.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187492 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed assertion in Extract128BitVector()


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187493 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Move compare-and-branch generation even later

r187116 moved compare-and-branch generation from the instruction-selection
pass to the peephole optimizer (via optimizeCompare).  It turns out that even
this is a bit too early.  Fused compare-and-branch instructions don't
interact well with predication, where a CC result is needed.  They also
make it harder to reuse the CC side-effects of earlier instructions
(not yet implemented, but the subject of a later patch).

Another problem was that the AnalyzeBranch family of routines weren't
handling compares and branches, so we weren't able to reverse the fused
form in cases where we would reverse a separate branch.  This could have
been fixed by extending AnalyzeBranch, but given the other problems,
I've instead moved the fusing to the long-branch pass, which is also
responsible for the opposite transformation: splitting out-of-range
compares and branches into separate compares and long branches.

I've added a test for the AnalyzeBranch problem.  A test for the
predication problem is included in the next patch, which fixes a bug
in the choice of CC mask.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187494 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Be more careful about inverting CC masks

System z branches have a mask to select which of the 4 CC values should
cause the branch to be taken.  We can invert a branch by inverting the mask.
However, not all instructions can produce all 4 CC values, so inverting
the branch like this can lead to some oddities.  For example, integer
comparisons only produce a CC of 0 (equal), 1 (less) or 2 (greater).
If an integer EQ is reversed to NE before instruction selection,
the branch will test for 1 or 2.  If instead the branch is reversed
after instruction selection (by inverting the mask), it will test for
1, 2 or 3.  Both are correct, but the second isn't really canonical.
This patch therefore keeps track of which CC values are possible
and uses this when inverting a mask.

Although this is mostly cosmestic, it fixes undefined behavior
for the CIJNLH in branch-08.ll.  Another fix would have been
to mask out bit 0 when generating the fused compare and branch,
but the point of this patch is that we shouldn't need to do that
in the first place.

The patch also makes it easier to reuse CC results from other instructions.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187495 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Be more careful about inverting CC masks (conditional loads)

Extend r187495 to conditional loads.  I split this out because the
easiest way seemed to be to force a particular operand order in
SystemZISelDAGToDAG.cpp.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187496 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Implement isLegalAddressingMode()

The loop optimizers were assuming that scales > 1 were OK.  I think this
is actually a bug in TargetLoweringBase::isLegalAddressingMode(),
since it seems to be trying to reject anything that isn't r+i or r+r,
but it has no default case for scales other than 0, 1 or 2.  Implementing
the hook for z means that z can no longer test any change there though.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187497 91177308-0d34-0410-b5e6-96231b3b80d8
Reject bitcasts between address spaces with different sizes

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187506 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Remove predicated_break inst

We were using two instructions for similar purpose : break and
predicated break. Only predicated_break was emitted and it was
lowered at R600ControlFlowFinalizer to JUMP;CF_BREAK;POP.
This commit simplify the situation by making AMDILCFGStructurizer
emit IF_PREDICATE;BREAK;ENDIF; instead of predicated_break (which
is now removed).

There is no functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187510 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen: Enumerate Schedule Model too.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187511 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Use SchedModel enum for is{Trans,Vector}Only functions

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187512 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Don't mix LDS and non-LDS instructions in the same group

There are a lot of restrictions on instruction groups that contain
LDS instructions, so for now we will be conservative and not packetize
anything else with them.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187513 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Non vector only instruction can be scheduled on trans unit

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187514 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Avoid more than 4 literals in the same instruction group at scheduling

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187515 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Do not mergevector after a vector reg is used

If we merge vector when a vector is used, it will generate an artificial
antidependency that can prevent 2 tex/vtx instructions to use the same
clause and thus generate extra clauses that reduce performance.

There is no test case as such situation is really hard to predict.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187516 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "R600: Use SchedModel enum for is{Trans,Vector}Only functions"

This reverts commit 3f1de26cb5cc0543a6a1d71259a7a39d97139051.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187524 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "TableGen: Enumerate Schedule Model too."

This reverts commit 2ca1e4a39c7e0d7a00e66ff5437c6d7ace2404a0.

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