llvm-svn: 190259

llvm-svn: 190258

precision loads and stores as well as reg+imm double precision loads and stores.

Previously, expansion of loads and stores was done after register allocation,
but now it takes place during legalization. As a result, users will see double
precision stores and loads being emitted to spill and restore 64-bit FP registers.

llvm-svn: 190235

llvm-svn: 190234

llvm-svn: 190232

into a 5-bit or 6-bit field.

llvm-svn: 190226

llvm-svn: 190224

llvm-svn: 190221

equivalent to "beq $zero, $zero, offset".

llvm-svn: 190220

llvm-svn: 190219

Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 190200

llvm-svn: 190156

Tested with 'llvm-tblgen -print-records' which outputs identical records before
and after this patch.

llvm-svn: 190155

This patch adds support for microMIPS Multiply and Add/Sub instructions. Test cases are included in patch.

llvm-svn: 190154

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190153

This patch adds support for microMIPS Move to/from HI/LO instructions. Test cases are included in patch.

llvm-svn: 190152

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190151

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190150

This patch adds support for microMIPS Move Conditional instructions. Test cases are included in patch.

llvm-svn: 190148

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190146

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190145

llvm-svn: 190144

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190143

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190142

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190141

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190140

The architecture has many comparison instructions, including some that
extend one of the operands.  The signed comparison instructions use sign
extensions and the unsigned comparison instructions use zero extensions.
In cases where we had a free choice between signed or unsigned comparisons,
we were trying to decide at lowering time which would best fit the available
instructions, taking things like extension type into account.  The code
to do that was getting increasingly hairy and was also making some bad
decisions.  E.g. when comparing the result of two LLCs, it is better to use
CR rather than CLR, since CR can be fused with a branch while CLR can't.

This patch removes the lowering code and instead adds an operand to
integer comparisons to say whether signed comparison is required,
whether unsigned comparison is required, or whether either is OK.
We can then leave the choice of instruction up to the normal isel code.

llvm-svn: 190138

No functional change

llvm-svn: 190134

Their default is to be the same as the result register set.

No functional change

llvm-svn: 190133

No functional change

llvm-svn: 190131

llvm-svn: 190130

llvm-svn: 190110

If the DAG already has only legal types, then the second round of DAG combines
is skipped. In this case VSELECT+SETCC patterns that match a more efficient
instruction (e.g. min/max) are never recognized.

This fix allows VSELECT+SETCC combines if the types are already legal before DAG
type legalization.

Reviewer: Nadav
llvm-svn: 190105

expression uses an assembler temporary symbol from an assignment.  In this case
the symbol does not have a fragment so the use of getFragment() would be NULL
and caused a crash. In the case of an assembler temporary symbol we want to use
the AliasedSymbol (if any) which will create a local relocation entry, but if
it is not an assembler temporary symbol then let it use that symbol with an
external relocation entry.

rdar://9356266

llvm-svn: 190096

llvm-svn: 190091

llvm-svn: 190080

llvm-svn: 190079

GlobalAdderss nodes that appeared in more than one basic block were
being counted twice.

llvm-svn: 190078

llvm-svn: 190077

This pass was segfaulting when it ran into a non-intrinsic function
call.  Function calls are not supported, so now instead of segfaulting,
we will get an assertion failure with a nice error message.

I'm not sure how to test this using lit.

llvm-svn: 190076