[SystemZ/z/OS] Add XPLINK 64-bit calling convention to tablegen.

This commit adds the initial changes to the SystemZ target
description for the XPLINK 64-bit calling convention on z/OS.
Additions in

[SystemZ/z/OS] Add XPLINK 64-bit calling convention to tablegen.

This commit adds the initial changes to the SystemZ target
description for the XPLINK 64-bit calling convention on z/OS.
Additions include:

- a new predicate IsTargetXPLINK64
- different register allocation order
- generaton of nopr after a call

Reviewed-by: uweigand

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

show more ...

[TableGen] Drop deprecated leading # operation (NOP) and replace ## with #

[SystemZ] Model floating-point control register

This adds the FPC (floating-point control register) as a reserved
physical register and models its use by SystemZ instructions.

Note that only the cu

[SystemZ] Model floating-point control register

This adds the FPC (floating-point control register) as a reserved
physical register and models its use by SystemZ instructions.

Note that only the current rounding modes and the IEEE exception
masks are modeled. *Changes* of the FPC due to exceptions (in
particular the IEEE exception flags and the DXC) are not modeled.

At this point, this patch is mostly NFC, but it will prevent
scheduling of floating-point instructions across SPFC/LFPC etc.

llvm-svn: 360570

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[SystemZ] Replace subreg_r with subreg_h

Change
subreg_r32 -> subreg_h32
subreg_r64 -> subreg_h64
subreg_hr32 -> subreg_hh32

The subregisters subreg_r32 and subreg_r64 were added to emphasi

[SystemZ] Replace subreg_r with subreg_h

Change
subreg_r32 -> subreg_h32
subreg_r64 -> subreg_h64
subreg_hr32 -> subreg_hh32

The subregisters subreg_r32 and subreg_r64 were added to emphasize the
fact that modifying these subregisters may clobber the entire register.
This is not necessarily the case for subreg_h32, et al.

However, the ability to compose subreg_h64 with subreg_r32, and with
subreg_h32 and subreg_l32 at the same time makes the compositions be
treated as non-overlapping (leading to problems when tracking subreg
liveness). See D50468 for more details.

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

llvm-svn: 339778

show more ...

[SystemZ] Do not use glue to represent condition code dependencies

Currently, an instruction setting the condition code is linked to
the instruction using the condition code via a "glue" link in the

[SystemZ] Do not use glue to represent condition code dependencies

Currently, an instruction setting the condition code is linked to
the instruction using the condition code via a "glue" link in the
SelectionDAG. This has a number of drawbacks; in particular, it
means the same CC cannot be used by multiple users. It also makes
it more difficult to efficiently implement SADDO et. al.

This patch changes the back-end to represent CC dependencies as
normal values during SelectionDAG matching, along the lines of
how this is handled in the X86 back-end already.

In addition to the core mechanics of updating all relevant patterns,
this requires a number of additional changes:

- We now need to be able to spill/restore a CC value into a GPR
if necessary. This means providing a copyPhysReg implementation
for moves involving CC, and defining getCrossCopyRegClass.

- Since we still prefer to avoid such spills, we provide an override
for IsProfitableToFold to avoid creating a merged LOAD / ICMP if
this would result in multiple users of the CC.

- combineCCMask no longer requires a single CC user, and no longer
need to be careful about preventing invalid glue/chain cycles.

- emitSelect needs to be more careful in marking CC live-in to
the basic block it generates. Also, we can now optimize the
case of multiple subsequent selects with the same condition
just like X86 does.

llvm-svn: 331202

show more ...

[SystemZ] Make AnyRegBitRegClass unallocatable.

AnyReg is just for the assembler and it is better to have it as not
allocatable in order to simplify (make more intuitive) the RegPressureSets.

Revi

[SystemZ] Make AnyRegBitRegClass unallocatable.

AnyReg is just for the assembler and it is better to have it as not
allocatable in order to simplify (make more intuitive) the RegPressureSets.

Review: Ulrich Weigand
llvm-svn: 327715

show more ...

[SystemZ] Support vector registers in inline asm

This adds support for specifying vector registers for use with inline
asm statements, either via the 'v' constraint or by explicit register
names (v0

[SystemZ] Support vector registers in inline asm

This adds support for specifying vector registers for use with inline
asm statements, either via the 'v' constraint or by explicit register
names (v0 ... v31).

llvm-svn: 326609

show more ...

[SystemZ] Add the CoveredBySubRegs bit to GPR64, GPR128 and FPR128 registers.

This bit is needed in order for the CalleeSavedRegs list to automatically
include the super registers if all of their s

[SystemZ] Add the CoveredBySubRegs bit to GPR64, GPR128 and FPR128 registers.

This bit is needed in order for the CalleeSavedRegs list to automatically
include the super registers if all of their subregs are present.

Thanks to Wei Mi for initially indicating this deficiency in the SystemZ
backend.

Review: Ulrich Weigand.
https://bugs.llvm.org/show_bug.cgi?id=34550

llvm-svn: 313023

show more ...

[SystemZ] Add support for IBM z14 processor (3/3)

This adds support for the new 128-bit vector float instructions of z14.
Note that these instructions actually only operate on the f128 type,
since o

[SystemZ] Add support for IBM z14 processor (3/3)

This adds support for the new 128-bit vector float instructions of z14.
Note that these instructions actually only operate on the f128 type,
since only each 128-bit vector register can hold only one 128-bit
float value. However, this is still preferable to the legacy 128-bit
float instructions, since those operate on pairs of floating-point
registers (so we can hold at most 8 values in registers), while the
new instructions use single vector registers (so we hold up to 32
value in registers).

Adding support includes:
- Enabling the instructions for the assembler/disassembler.
- CodeGen for the instructions. This includes allocating the f128
type now to the VR128BitRegClass instead of FP128BitRegClass.
- Scheduler description support for the instructions.

Note that for a small number of operations, we have no new vector
instructions (like integer <-> 128-bit float conversions), and so
we use the legacy instruction and then reformat the operand
(i.e. copy between a pair of floating-point registers and a
vector register).

llvm-svn: 308196

show more ...

[SystemZ] Add support for IBM z14 processor (2/3)

This adds support for the new 32-bit vector float instructions of z14.
This includes:
- Enabling the instructions for the assembler/disassembler.
-

[SystemZ] Add support for IBM z14 processor (2/3)

This adds support for the new 32-bit vector float instructions of z14.
This includes:
- Enabling the instructions for the assembler/disassembler.
- CodeGen for the instructions, including new LLVM intrinsics.
- Scheduler description support for the instructions.
- Update to the vector cost function calculations.

In general, CodeGen support for the new v4f32 instructions closely
matches support for the existing v2f64 instructions.

llvm-svn: 308195

show more ...

[SystemZ] Add all remaining instructions

This adds all remaining instructions that were still missing, mostly
privileged and semi-privileged system-level instructions. These are
provided for use wi

[SystemZ] Add all remaining instructions

This adds all remaining instructions that were still missing, mostly
privileged and semi-privileged system-level instructions. These are
provided for use with the assembler and disassembler only.

This brings the LLVM assembler / disassembler to parity with the
GNU binutils tools.

llvm-svn: 306876

show more ...

[SystemZ] Model access registers as LLVM registers

Add the 16 access registers as LLVM registers. This allows removing
a lot of special cases in the assembler and disassembler where we
were handlin

[SystemZ] Model access registers as LLVM registers

Add the 16 access registers as LLVM registers. This allows removing
a lot of special cases in the assembler and disassembler where we
were handling access registers; this can all just use the generic
register code now.

Also add a bunch of instructions to operate on access registers,
for assembler/disassembler use only. No change in code generation
intended.

llvm-svn: 286283

show more ...

[SystemZ] Add support for the .insn directive

Summary:
Add support for the .insn directive.

.insn is an s390 specific directive that allows encoding of an instruction
instead of using a mnemonic. T

[SystemZ] Add support for the .insn directive

Summary:
Add support for the .insn directive.

.insn is an s390 specific directive that allows encoding of an instruction
instead of using a mnemonic. The motivating case is some code in node.js that
requires support for the .insn directive.

Reviewers: koriakin, uweigand

Subscribers: koriakin, llvm-commits

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

llvm-svn: 278012

show more ...

[SystemZ] Make the CCRegs regclass non-allocatable.

This was discovered to be necessary while running memchr-01.ll with
-verify-machinstrs, because it is not allowed to have a phys reg live
accross

[SystemZ] Make the CCRegs regclass non-allocatable.

This was discovered to be necessary while running memchr-01.ll with
-verify-machinstrs, because it is not allowed to have a phys reg live
accross block boundaries while on SSA form, if the register is
allocatable (expect in entry block and landing pads).

In this test case, stringRRE pseudos are expanded after isel by adding
a loop block which produces a live out CC register. To make the test
pass, it was also necessary to not say that StringRRELoop pseudo uses
R0L, this is only true for the StringRRE opcode.

-verify-machineinstrs added to memchr-01.ll test.

New test case int-cmp-51.ll to test that MachineCSE can eliminate
an identical compare (which it couldn't do before).

Reviewed by Ulrich Weigand

llvm-svn: 251634

show more ...

[SystemZ] Add z13 vector facility and MC support

This patch adds support for the z13 processor type and its vector facility,
and adds MC support for all new instructions provided by that facilily.

[SystemZ] Add z13 vector facility and MC support

This patch adds support for the z13 processor type and its vector facility,
and adds MC support for all new instructions provided by that facilily.

Apart from defining the new instructions, the main changes are:

- Adding VR128, VR64 and VR32 register classes.
- Making FP64 a subclass of VR64 and FP32 a subclass of VR32.
- Adding a D(V,B) addressing mode for scatter/gather operations
- Adding 1-, 2-, and 3-bit immediate operands for some 4-bit fields.
Until now all immediate operands have been the same width as the
underlying field (hence the assert->return change in decode[SU]ImmOperand).

In addition, sys::getHostCPUName is extended to detect running natively
on a z13 machine.

Based on a patch by Richard Sandiford.

llvm-svn: 236520

show more ...

[SystemZ] Reclassify f32 subregs of f64 registers

At the moment, all subregs defined by the SystemZ target can be modified
independently of the wider register. E.g. writing to a GR32 does not
chang

[SystemZ] Reclassify f32 subregs of f64 registers

At the moment, all subregs defined by the SystemZ target can be modified
independently of the wider register. E.g. writing to a GR32 does not
change the upper 32 bits of the GR64. Writing to an FP32 does not change
the lower 32 bits of the FP64.

Hoewver, the upcoming support for the vector extension redefines FP64 as
one half of a V128. Floating-point operations leave the other half of
a V128 in an unpredictable state, so it's no longer the case that writing
to an FP32 leaves the bits of the underlying register (the V128) alone.
I'd prefer to have separate subreg_ names for this situation, so that
it's obvious at a glance whether we're talking about a subreg that leaves
the other parts of the register alone.

No behavioral change intended.

Patch originally by Richard Sandiford.

llvm-svn: 236433

show more ...

[SystemZ] Fix FPR dwarf numbering

The dwarf FPR numbers are supposed to have the order F0, F2, F4, F6,
F1, F3, F5, F7, F8, etc., which matches the pairing of registers for
long doubles. E.g. a long

[SystemZ] Fix FPR dwarf numbering

The dwarf FPR numbers are supposed to have the order F0, F2, F4, F6,
F1, F3, F5, F7, F8, etc., which matches the pairing of registers for
long doubles. E.g. a long double stored in F0 is paired with F2.

llvm-svn: 212701

show more ...

[SystemZ] Use upper words of GR64s for codegen

This just adds the basics necessary for allocating the upper words to
virtual registers (move, load and store). The move support is parameterised
in a

[SystemZ] Use upper words of GR64s for codegen

This just adds the basics necessary for allocating the upper words to
virtual registers (move, load and store). The move support is parameterised
in a way that makes it easy to handle zero extensions, but the associated
zero-extend patterns are added by a later patch.

The easiest way of testing this seemed to be add a new "h" register
constraint for high words. I don't expect the constraint to be useful
in real inline asms, but it should work, so I didn't try to hide it
behind an option.

llvm-svn: 191739

show more ...

[SystemZ] Add GRH32 for the high word of a GR64

The only thing this does on its own is make the definitions of RISB[HL]G
a bit more precise. Those instructions are only used by the MC layer at
the

[SystemZ] Add GRH32 for the high word of a GR64

The only thing this does on its own is make the definitions of RISB[HL]G
a bit more precise. Those instructions are only used by the MC layer at
the moment, so no behavioral change is intended. The class is needed by
later patches though.

llvm-svn: 191660

show more ...

[SystemZ] Rename subregs and add subreg_h32

Use subreg_hNN and subreg_lNN for the high and low NN bits of a register.
List the low registers first, so that subreg_l32 also means the low 32
bits of a

[SystemZ] Rename subregs and add subreg_h32

Use subreg_hNN and subreg_lNN for the high and low NN bits of a register.
List the low registers first, so that subreg_l32 also means the low 32
bits of a 128-bit register.

Floats are stored in the upper 32 bits of a 64-bit register, so they
should use subreg_h32 rather than subreg_l32.

No behavioral change intended.

llvm-svn: 191659

show more ...

[SystemZ] Add change missing from previous commit

llvm-svn: 191656

[SystemZ] Rename 32-bit GPR registers

I'm about to add support for high-word operations, so it seemed better
for the low-word registers to have names like R0L rather than R0W.
No behavioral change i

[SystemZ] Rename 32-bit GPR registers

I'm about to add support for high-word operations, so it seemed better
for the low-word registers to have names like R0L rather than R0W.
No behavioral change intended.

llvm-svn: 191655

show more ...

[SystemZ] Fix parsing of inline asm registers

GPR and FPR constraints like "{r2}" and "{f2}" weren't handled correctly
because the name-to-regno mapping depends on the value type and
(because of tha

[SystemZ] Fix parsing of inline asm registers

GPR and FPR constraints like "{r2}" and "{f2}" weren't handled correctly
because the name-to-regno mapping depends on the value type and
(because of that) the internal names in RegStrings are not the
same as the AsmName.

CC constraints like "{cc}" didn't work either because there was no
associated register class.

llvm-svn: 186148

show more ...

Make SubRegIndex size mandatory, following r183020.

This also makes TableGen able to compute sizes/offsets of synthesized
indices representing tuples.

llvm-svn: 183061