Just define the address as unknown instead of VReg_32.

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 178022

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 178021

They read from constant register space anyway.

v2: fix lit tests

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 178020

Just enable WQM when we see an LDS interpolation instruction.

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 178019

Restore the EXEC mask early, otherwise a copy might end up not beeing executed.

Candidate for the mesa stable branch.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 178018

If PC or SP is the destination, the disassembler erroneously failed with the
invalid encoding, despite the manual saying that both are fine.

This patch addresses failure to decode encoding T4 of LDR (A8.8.62) which is a
postindexed load, where the offset 0xc is applied to SP after the load occurs.

llvm-svn: 178017

There remain a number of patterns that cannot (and should not)
be handled by the asm parser, in particular all the Pseudo patterns.

This commit marks those patterns as isCodeGenOnly.

No change in generated code.

llvm-svn: 178008

MCTargetDesc/PPCMCCodeEmitter.cpp current has code like:

 if (isSVR4ABI() && is64BitMode())
   Fixups.push_back(MCFixup::Create(0, MO.getExpr(),
                                    (MCFixupKind)PPC::fixup_ppc_toc16));
 else
   Fixups.push_back(MCFixup::Create(0, MO.getExpr(),
                                    (MCFixupKind)PPC::fixup_ppc_lo16));

This is a problem for the asm parser, since it requires knowledge of
the ABI / 64-bit mode to be set up.  However, more fundamentally,
at this point we shouldn't make such distinctions anyway; in an assembler
file, it always ought to be possible to e.g. generate TOC relocations even
when the main ABI is one that doesn't use TOC.

Fortunately, this is actually completely unnecessary; that code was added
to decide whether to generate TOC relocations, but that information is in
fact already encoded in the VariantKind of the underlying symbol.

This commit therefore merges those fixup types into one, and then decides
which relocation to use based on the VariantKind.

No changes in generated code.

llvm-svn: 178007

As part of the the sequence generated to implement long double -> int
conversions, we need to perform an FADD in round-to-zero mode.  This is
problematical since the FPSCR is not at all modeled at the SelectionDAG
level, and thus there is a risk of getting floating point instructions
generated out of sequence with the instructions to modify FPSCR.

The current code handles this by somewhat "special" patterns that in part
have dummy operands, and/or duplicate existing instructions, making them
awkward to handle in the asm parser.

This commit changes this by leaving the "FADD in round-to-zero mode"
as an atomic operation on the SelectionDAG level, and only split it up into
real instructions at the MI level (via custom inserter).  Since at *this*
level the FPSCR *is* modeled (via the "RM" hard register), much of the
"special" stuff can just go away, and the resulting patterns can be used by
the asm parser.

No significant change in generated code expected.

llvm-svn: 178006

The LDrs pattern is a duplicate of LD, except that it accepts memory
addresses where the displacement is a symbolLo64.  An operand type
"memrs" is defined for just that purpose.

However, this wouldn't be necessary if the default "memrix" operand
type were to simply accept 64-bit symbolic addresses directly.
The only problem with that is that it uses "symbolLo", which is
hardcoded to 32-bit.

To fix this, this commit changes "memri" and "memrix" to use new
operand types for the memory displacement, which allow iPTR
instead of i32.  This will also make address parsing easier to
implment in the asm parser.

No change in generated code.

llvm-svn: 178005

The ADDI/ADDI8 patterns are currently duplicated into ADDIL/ADDI8L,
which describe the same instruction, except that they accept a
symbolLo[64] operand instead of a s16imm[64] operand.

This duplication confuses the asm parser, and it actually not really
needed, since symbolLo[64] already accepts immediate operands anyway.
So this commit removes the duplicate patterns.

No change in generated code.

llvm-svn: 178004

This commit changes the ISEL patterns to use a CCBITRC operand
instead of a "pred" operand.  This matches the actual instruction
text more directly, and simplifies use of ISEL with the asm parser.
In addition, this change allows some simplification of handling
the "pred" operand, as this is now only used by BCC.

No change in generated code.

llvm-svn: 178003

The BLR pattern cannot be recognized by the asm parser in its current form.
This complexity is due to an apparent attempt to enable conditional BLR
variants.  However, none of those can ever be generated by current code;
the pattern is only ever created using the default "pred" operand.

To simplify the pattern and allow it to be recognized by the parser,
this commit removes those attempts at conditional BLR support.

When we later come back to actually add real conditional BLR, this
should probably be done via a fully generic conditional branch pattern.

No change in generated code.

llvm-svn: 178002

In PPCInstr64Bit.td, some branch patterns appear in a different sequence
than the corresponding 32-bit patterns in PPCInstrInfo.td.

To simplify future changes that affect both files, this commit moves
those patterns to rearrange them into a similar sequence.

No effect on generated code.

llvm-svn: 178001

Use a MapVector on types where the iteration order matters.
Otherwise we doesn't always produce a deterministic output.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 177999

Move the CortexA9 resources into the CortexA9 SchedModel namespace. Define
resource mappings under the CortexA9 SchedModel. Define resources and mappings
for the SwiftModel.

llvm-svn: 177968

This is very much work in progress. Please send me a note if you start to depend
on the added abstract read/write resources. They are subject to change until
further notice.

The old itinerary is still the default.

llvm-svn: 177967

- It's still considered aligned when the specified alignment is larger
  than the natural alignment;
- The new alignment for the high 128-bit vector should be min(16,
  alignment) as the pointer is advanced by 16, a power-of-2 offset.

llvm-svn: 177947

The model isn't hooked up by this patch because the instruction set
isn't fully annotated yet.

llvm-svn: 177942

All the instructions tagged with IIC_DEFAULT had nothing in common, and
we already have a NoItineraries class to represent untagged
instructions.

llvm-svn: 177937

llvm-svn: 177936

llvm-svn: 177935

llvm-svn: 177910

llvm-svn: 177909

llvm-svn: 177899

This commit updates the PowerPC back-end (PPCInstrInfo.td and
PPCInstr64Bit.td) to use types instead of register classes in
instruction patterns, along the lines of Jakob Stoklund Olesen's
changes in r177835 for Sparc.
 

llvm-svn: 177890

This commit updates the PowerPC back-end (PPCInstrInfo.td and
PPCInstr64Bit.td) to use types instead of register classes in
Pat patterns, along the lines of Jakob Stoklund Olesen's
changes in r177829 for Sparc.

llvm-svn: 177889

llvm-svn: 177888

This fixes Apple bug: 13493622

llvm-svn: 177887

llvm-svn: 177878

sure the base register and would-be writeback register don't conflict for
stores.  This was already being done for loads.

Unfortunately, it is rather difficult to create a test case for this issue.  It
was exposed in 450.soplex at LTO and requires unlucky register allocation.
<rdar://13394908>

llvm-svn: 177874

llvm-svn: 177847

The types of register variables no longer need to be specified in output
patterns.

llvm-svn: 177845

Also update the documentation since Sparc is the nicest backend, and
used as an example in WritingAnLLVMBackend.

llvm-svn: 177835

In order for the new ZERO register to be used with MC, etc. we need to specify
its register number (0).

Thanks to Kai for reporting the problem!

llvm-svn: 177833

In preparation for using the new register scavenger capability for providing
more than one register simultaneously, specifically note functions that have
spilled VRSAVE (currently, this can happen only in functions that use the
setjmp intrinsic). As with CR spilling, such functions will need to provide two
emergency spill slots to the scavenger.

No functionality change intended.

llvm-svn: 177832

I recently added a BCL instruction definition as part of implementing SjLj
support. This can also be used to MCize bcl emission in the asm printer.

No functionality change intended.

llvm-svn: 177830

The SelectionDAG graph has MVT type labels, not register classes, so
this makes it clearer what is happening.

This notation is also robust against adding more types to the IntRegs
register class.

llvm-svn: 177829

These spilling functions will eventually make use of the register scavenger,
however, they'll do so by taking advantage of PEI's virtual-register-based
delayed scavenging mechanism. As a result, these function parameters will not
be used, and can be removed.

No functionality change intended.

llvm-svn: 177827

The LR register is unconditionally reserved, and its spilling and restoration
is handled by the prologue/epilogue code. As a result, it is never explicitly
spilled by the register allocator.

No functionality change intended.

llvm-svn: 177823