Move Post RA Scheduling flag bit into SchedMachineModel

Refactoring; no functional changes intended

Removed PostRAScheduler bits from subtargets (X86, ARM).
Added PostRAScheduler bit to MCS

Move Post RA Scheduling flag bit into SchedMachineModel

Refactoring; no functional changes intended

Removed PostRAScheduler bits from subtargets (X86, ARM).
Added PostRAScheduler bit to MCSchedModel class.
This bit is set by a CPU's scheduling model (if it exists).
Removed enablePostRAScheduler() function from TargetSubtargetInfo and subclasses.
Fixed the existing enablePostMachineScheduler() method to use the MCSchedModel (was just returning false!).
Added methods to TargetSubtargetInfo to allow overrides for AntiDepBreakMode, CriticalPathRCs, and OptLevel for PostRAScheduling.
Added enablePostRAScheduler() function to PostRAScheduler class which queries the subtarget for the above values.
Preserved existing scheduler behavior for ARM, MIPS, PPC, and X86:
a. ARM overrides the CPU's postRA settings by enabling postRA for any non-Thumb or Thumb2 subtarget.
b. MIPS overrides the CPU's postRA settings by enabling postRA for everything.
c. PPC overrides the CPU's postRA settings by enabling postRA for everything.
d. X86 is the only target that actually has postRA specified via sched model info.

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

llvm-svn: 213101

show more ...

[mips] For the FP64A ABI, odd-numbered double-precision moves must not use mtc1/mfc1.

Summary:
This is because the FP64A the hardware will redirect 32-bit reads/writes
from/to odd-numbered registers

[mips] For the FP64A ABI, odd-numbered double-precision moves must not use mtc1/mfc1.

Summary:
This is because the FP64A the hardware will redirect 32-bit reads/writes
from/to odd-numbered registers to the upper 32-bits of the corresponding
even register. In effect, simulating FR=0 mode when FR=0 mode is not
available.

Unfortunately, we have to make the decision to avoid mfc1/mtc1 before
register allocation so we currently do this for even registers too.

FPXX has a similar requirement on 32-bit architectures that lack
mfhc1/mthc1 so this patch also handles the affected moves from the FPU for
FPXX too. Moves to the FPU were supported by an earlier commit.

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

llvm-svn: 212938

show more ...

[mips] Expand BuildPairF64 to a spill and reload when the O32 FPXX ABI is
enabled and mthc1 and dmtc1 are not available (e.g. on MIPS32r1)

This prevents the upper 32-bits of a double precision value

[mips] Expand BuildPairF64 to a spill and reload when the O32 FPXX ABI is
enabled and mthc1 and dmtc1 are not available (e.g. on MIPS32r1)

This prevents the upper 32-bits of a double precision value from being moved to
the FPU with mtc1 to an odd-numbered FPU register. This is necessary to ensure
that the code generated executes correctly regardless of the current FPU mode.

MIPS32r2 and above continues to use mtc1/mthc1, while MIPS-IV and above continue
to use dmtc1.

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

llvm-svn: 212930

show more ...

[mips] Added FPXX modeless calling convention.
Differential Revision: http://reviews.llvm.org/D4293

llvm-svn: 212726

[mips] Add support for -modd-spreg/-mno-odd-spreg

Summary:
When -mno-odd-spreg is in effect, 32-bit floating point values are not
permitted in odd FPU registers. The option also prohibits 32-bit and

[mips] Add support for -modd-spreg/-mno-odd-spreg

Summary:
When -mno-odd-spreg is in effect, 32-bit floating point values are not
permitted in odd FPU registers. The option also prohibits 32-bit and 64-bit
floating point comparison results from being written to odd registers.

This option has three purposes:
* It allows support for certain MIPS implementations such as loongson-3a that
do not allow the use of odd registers for single precision arithmetic.
* When using -mfpxx, -mno-odd-spreg is the default and this allows us to
statically check that code is compliant with the O32 FPXX ABI since mtc1/mfc1
instructions to/from odd registers are guaranteed not to appear for any
reason. Once this has been established, the user can then re-enable
-modd-spreg to regain the use of all 32 single-precision registers.
* When using -mfp64 and -mno-odd-spreg together, an O32 extension named
O32 FP64A is used as the ABI. This is intended to provide almost all
functionality of an FR=1 processor but can also be executed on a FR=0 core
with the assistance of a hardware compatibility mode which emulates FR=0
behaviour on an FR=1 processor.

* Added '.module oddspreg' and '.module nooddspreg' each of which update
the .MIPS.abiflags section appropriately
* Moved setFpABI() call inside emitDirectiveModuleFP() so that the caller
doesn't have to remember to do it.
* MipsABIFlags now calculates the flags1 and flags2 member on demand rather
than trying to maintain them in the same format they will be emitted in.

There is one portion of the -mfp64 and -mno-odd-spreg combination that is not
implemented yet. Moves to/from odd-numbered double-precision registers must not
use mtc1. I will fix this in a follow-up.

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

llvm-svn: 212717

show more ...

Move subtarget dependent features into the subtarget from the target
machine. Includes a fix for a subtarget initialization for
hard floating point on mips16.

llvm-svn: 212240

Move the data layout and selection dag info from the mips target machine
down to the subtarget.

llvm-svn: 212224

Break out subtarget initialization that dependent variables need into
a separate function and clean up calling convention for helper function.

llvm-svn: 212153

Unify these two lines.

llvm-svn: 212152

Move MipsJITInfo to the subtarget rather than the target machine.

llvm-svn: 212151

[mips] Marked up instructions added in MIPS32r2 and tested that IAS for -mcpu=mips(2|32) does not accept them

Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-3

[mips] Marked up instructions added in MIPS32r2 and tested that IAS for -mcpu=mips(2|32) does not accept them

Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-3 that was available in MIPS32R2.

To limit the number of tests required, only one 32-bit and one 64-bit ISA
prior to MIPS32/MIPS64 are tested.

rdhwr has been deliberately left without an ISA annotation for now. This is
because the assembler and CodeGen disagree on when the instruction is
available. Strictly speaking, it is only available in MIPS32r2 and
MIPS64r2. However, it is emulated by a kernel trap on earlier ISA's and is
necessary for TLS so CodeGen should emit it on older ISA's too.

Depends on D3696

Reviewers: vmedic

Reviewed By: vmedic

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

llvm-svn: 208690

show more ...

[mips] Marked up instructions added in MIPS-V and tested that IAS for -mcpu=mips[1234] does not accept them

Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-V th

[mips] Marked up instructions added in MIPS-V and tested that IAS for -mcpu=mips[1234] does not accept them

Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-V that was available in MIPS32R2

Most of these instructions are correctly rejected but with the wrong error
message. These have been placed in a separate test for now. It happens
because many of the MIPS V instructions have not been implemented.

Depends on D3694

Reviewers: vmedic

Reviewed By: vmedic

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

llvm-svn: 208546

show more ...

[mips] Fold FeatureBitCount into FeatureMips32 and FeatureMips64

Summary:
DCL[ZO] are now correctly marked as being MIPS64 instructions. This has no
effect on the CodeGen tests since expansion of i6

[mips] Fold FeatureBitCount into FeatureMips32 and FeatureMips64

Summary:
DCL[ZO] are now correctly marked as being MIPS64 instructions. This has no
effect on the CodeGen tests since expansion of i64 prevented their use
anyway.

The check for MIPS16 to prevent the use of CLZ no longer prevents DCLZ as
well. This is not a functional change since DCLZ is still prohibited by
being a MIPS64 instruction (MIPS16 is only compatible with MIPS32).

No functional change

Reviewers: vmedic

Reviewed By: vmedic

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

llvm-svn: 208544

show more ...

[mips] Fold FeatureSEInReg into FeatureMips32r2

Summary: No functional change

Reviewers: vmedic

Reviewed By: vmedic

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

llvm-svn: 208543

[mips] Fold FeatureSwap into FeatureMips32r2 and FeatureMips64r2

Summary:
dsbh and dshd are not available on Mips32r2. No codegen test changes
required since expansion of i64 prevented the use of th

[mips] Fold FeatureSwap into FeatureMips32r2 and FeatureMips64r2

Summary:
dsbh and dshd are not available on Mips32r2. No codegen test changes
required since expansion of i64 prevented the use of these instructions
anyway.

Depends on D3690

Reviewers: vmedic

Reviewed By: vmedic

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

llvm-svn: 208542

show more ...

[mips] Replace FeatureFPIdx with FeatureMips4_32r2

Summary:
No functional change.

The minor change to the MIPS16 code is in preparation for a patch that will handle 32-bit FPIdx instructions separa

[mips] Replace FeatureFPIdx with FeatureMips4_32r2

Summary:
No functional change.

The minor change to the MIPS16 code is in preparation for a patch that will handle 32-bit FPIdx instructions separately to 64-bit (because they were added in different revisions)

Depends on D3677

Reviewers: rkotler, vmedic

Reviewed By: vmedic

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

llvm-svn: 208541

show more ...

[mips] Marked up instructions added in MIPS-IV and tested that IAS for -mcpu=mips[123] does not accept them

Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-IV t

[mips] Marked up instructions added in MIPS-IV and tested that IAS for -mcpu=mips[123] does not accept them

Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-IV that was available in MIPS32

A small number of instructions are correctly rejected but with the wrong error
message. These have been placed in a separate test for now.

Depends on D3676

Reviewers: vmedic

Reviewed By: vmedic

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

llvm-svn: 208414

show more ...

[mips] Remove unused CondMov feature bit

Summary:
No functional change

Depends on D3675

Reviewers: vmedic

Reviewed By: vmedic

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

llvm-svn: 2084

[mips] Remove unused CondMov feature bit

Summary:
No functional change

Depends on D3675

Reviewers: vmedic

Reviewed By: vmedic

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

llvm-svn: 208410

show more ...

[mips] Marked up instructions added in MIPS-III and tested that IAS for -mcpu=mips[12] does not accept them

Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-III

[mips] Marked up instructions added in MIPS-III and tested that IAS for -mcpu=mips[12] does not accept them

Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-III that was available in MIPS32

A small number of instructions are correctly rejected but with the wrong error
message. These have been placed in a separate test for now.

There's some obvious InstAlias's that ought to be marked MIPS-III but arent.
This is because they are not currently tested. I intend to catch these with
a final pass through the tablegen records to find tablegen records without
ISA annotations.

Depends on D3674

Reviewers: vmedic

Reviewed By: vmedic

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

llvm-svn: 208408

show more ...

[mips][mips64r6] Add experimental support for MIPS32r6 and MIPS64r6

Summary:
Adds MIPS32r6/MIPS64r6 and checks the compatibility requirements for these
processors.

I've also included comments to de

[mips][mips64r6] Add experimental support for MIPS32r6 and MIPS64r6

Summary:
Adds MIPS32r6/MIPS64r6 and checks the compatibility requirements for these
processors.

I've also included comments to describe removed and re-encoded instructions,
along with placeholder def's for the new instructions but there are no
functional changes to codegen at this point.

Reviewers: jkolek, vmedic

Reviewed By: vmedic

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

llvm-svn: 208399

show more ...

[mips] Add highly experimental support for MIPS-I, MIPS-II, MIPS-III, and MIPS-V

Summary:
These processors will only be available for the integrated assembler at
first (CodeGen will emit a fatal err

[mips] Add highly experimental support for MIPS-I, MIPS-II, MIPS-III, and MIPS-V

Summary:
These processors will only be available for the integrated assembler at
first (CodeGen will emit a fatal error saying they are not implemented).

The intention is to work through the existing instructions and correctly
annotate the ISA they were added in so that we have a sufficiently good
base to start MIPS64r6 development. MIPS64r6 removes/re-encodes certain
instructions and I believe it is best to define ISA's using set-union's
as far as possible rather than using set-subtraction.

Reviewers: vmedic

Subscribers: emaste, llvm-commits

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

llvm-svn: 208221

show more ...

[Modules] Fix potential ODR violations by sinking the DEBUG_TYPE
definition below all of the header #include lines, lib/Target/...
edition.

llvm-svn: 206842

[cleanup] Lift using directives, DEBUG_TYPE definitions, and even some
system headers above the includes of generated '.inc' files that
actually contain code. In a few targets this was already done p

[cleanup] Lift using directives, DEBUG_TYPE definitions, and even some
system headers above the includes of generated '.inc' files that
actually contain code. In a few targets this was already done pretty
consistently, but it wasn't done *really* consistently anywhere. It is
strictly cleaner IMO and necessary in a bunch of places where the
DEBUG_TYPE is referenced from the generated code. Consistency with the
necessary places trumps. Hopefully the build bots are OK with the
movement of intrin.h...

llvm-svn: 206838

show more ...

[mips] Add initial support for NaN2008 in the back-end.

This is so that EF_MIPS_NAN2008 is set if we are using IEEE 754-2008
NaN encoding (-mnan=2008). This patch also adds support for parsing
'.nan

[mips] Add initial support for NaN2008 in the back-end.

This is so that EF_MIPS_NAN2008 is set if we are using IEEE 754-2008
NaN encoding (-mnan=2008). This patch also adds support for parsing
'.nan legacy' and '.nan 2008' assembly directives. The handling of
these directives should match GAS' behaviour i.e., the last directive
in use sets the ELF header bit (EF_MIPS_NAN2008).

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

llvm-svn: 206396

show more ...

[mips] Correct r206370 to account for non-Linux targets using the small data section.

This should fix the ninja-x64-msvc-RA-centos6 builder.

I suspect the check in MipsSubtarget.cpp is incorrect an

[mips] Correct r206370 to account for non-Linux targets using the small data section.

This should fix the ninja-x64-msvc-RA-centos6 builder.

I suspect the check in MipsSubtarget.cpp is incorrect and is really trying to
check for a bare-metal target rather and anything other than linux. I'll
investigate this.

llvm-svn: 206385

show more ...