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

llvm-svn: 286282

Summary: When moving all code to new.h/cc,  these code also will be formatted based on the given code style.

Reviewers: ioeric

Subscribers: cfe-commits

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

llvm-svn: 286281

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

llvm-svn: 286280

llvm-svn: 286279

Fixes post-commit review comment from r286177.

llvm-svn: 286275

Since IMPLIFIT_DEF instructions are omitted in the output, when the output
of an IMPLICIT_DEF instruction is stackified, the resulting register lacks
an explicit push, leading to a push/pop mismatch. Fix this by converting
such IMPLICIT_DEFs into CONST_I32 0 instructions so that they have explicit
pushes.

llvm-svn: 286274

This is helpful when multiple instructions are inserted.

llvm-svn: 286273

Erasing reverse_iterators is problematic; iterate manually.
While there, keep track of the range of inserted instructions.
It can miss instructions inserted elsewhere, but those are harder
to track.

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

llvm-svn: 286272

For example, it invalidates the domtree, causing assertions
in later passes which need dominator infos. Make it preserve
GlobalsAA, as suggested by Eli.

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

llvm-svn: 286271

llvm-svn: 286270

llvm-svn: 286269

Define a couple of additional semantic classes and use them
throughout the .td files to make them more consistent and
more easily readable.

No functional change.

llvm-svn: 286268

This changes the InstRR (and related) patterns to no longer
automatically add an "r" at the end of the mnemonic.  This
makes the .td files more obviously understandable, and also
allows using the patterns for those few instructions that
do not follow the *r scheme.

Also add some more sub-formats of the RRF format class, to
match operand names and sequence from the PoP better.

No functional change.

llvm-svn: 286267

Now that we've added instruction format subclasses like
InstRIb, it makes sense to rename the old InstRI to InstRIa.

Similar for InstRX, InstRXY, InstRS, InstRSY, and InstSS.

No functional change.

llvm-svn: 286266

Reviewers: t.p.northover, rengolin

Subscribers: llvm-commits, aemerson

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

llvm-svn: 286265

This reverts commit r286262. I accidentally committed it without all of
the changes.

llvm-svn: 286264

Rework patterns for branches, call & return instructions,
compare-and-branch, compare-and-trap, and conditional move
instructions.

In particular, simplify creation of patterns for the extended
opcodes of instructions that take a CC mask.

Also, use semantical instruction classes for all the instructions
instead of open-coding them in SystemZInstrInfo.td.

Adds a couple of the basic branch instructions (that are unused
for codegen) for the assembler/disassembler.

llvm-svn: 286263

llvm-svn: 286262

Avoids having to skip them multiple times.

llvm-svn: 286261

llvm-svn: 286260

About when we should move a vreg from CurrentNewVRegs to NewVRegs,
if the vreg in CurrentNewVRegs was added into RecoloringCandidate and was
evicted, it shouldn't be added to NewVRegs because its physical register
will be restored at the end of tryLastChanceRecoloring after the recoloring
failed. If the vreg in CurrentNewVRegs was not in RecoloringCandidate, i.e.
it was evicted in selectOrSplitImpl inside tryRecoloringCandidates, its
physical register will not be restored even if the recoloring failed. In
that case, we need to add the vreg to NewVRegs.

Same as r281783, the problem was seen on out-of-tree target and we didn't
have a test case that reproduce the problem with in-tree targets.

llvm-svn: 286259

Oops!

llvm-svn: 286258

llvm-svn: 286257

llvm-svn: 286256

llvm-svn: 286255

Not sure why this didn't explode more massively, but this should fix the issue with the non-framework tests.

llvm-svn: 286254

llvm-svn: 286253

Summary: In addition, the branch instructions will have proper BB destinations, not offsets, like before.

Reviewers: asl

Subscribers: llvm-commits

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

llvm-svn: 286252

llvm-svn: 286250

llvm-svn: 286249

llvm-svn: 286247

From experiments, discriminator is rarely greater than 127. Here we enforce it to be no greater than 127 so that it will always fit in 1 byte.

llvm-svn: 286245

Differential revision: https://reviews.llvm.org/D26397

llvm-svn: 286244

In Format, remove the reformat() and clean() functions taking a SourceManager
and a FileID. Keep the versions taking StringRef Code.

- there was duplicated functionality
- the FileID versions were harder to use
- the clean() version is dead code anyways

Patch by Krasimir Georgiev. Thank you.

llvm-svn: 286243

llvm-svn: 286242

llvm-svn: 286241

Thanks to Malcolm Parsons who pointed on that.

llvm-svn: 286239

Fixed an issue with vector usage of TargetLowering::isConstTrueVal / TargetLowering::isConstFalseVal boolean result matching.

The comment said we shouldn't handle constant splat vectors with undef elements. But the the actual code was returning false if the build vector contained no undef elements....

This patch now ignores the number of undefs (getConstantSplatNode will return null if the build vector is all undefs).

The change has also unearthed a couple of missed opportunities in AVX512 comparison code that will need to be addressed.

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

llvm-svn: 286238

We can just use a regular InputSection.

llvm-svn: 286237