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

This removes the custom ISD Node: MEMBARRIER and replaces it
with an intrinsic.

llvm-svn: 190055

These were pretty straightforward instructions, with some assembly support
required for HLT.

The ARM assembler is keen to split the instruction mnemonic into a
(non-existent) 'H' instruction with the LT condition code. An exception for
HLT is needed.

HLT follows the same rules as BKPT when in IT blocks, so the special BKPT
hadling code has been adapted to handle HLT also.

Regression tests added including diagnostic tests for out of range immediates
and illegal condition codes, as well as negative tests for pre-ARMv8.

llvm-svn: 190053

Solution is not sufficient to prevent 'mov pc, lr' being emitted for jump table code.
Test case doesn't trigger the added functionality.

llvm-svn: 190047

This improves code generation for jump tables by avoiding the emission of "mov pc, lr" which could fool the processor into believing this is a return from a function causing mispredicts. The code generation logic for jump tables uses ADR to materialize the address of the jump target.

Patch by Daniel Stewart!
   

llvm-svn: 190043

For now these are just used to handle scalar ANDs, ORs and XORs in which
all operands are memory.

llvm-svn: 190041

In sparc, setjmp stores only the registers %fp, %sp, %i7 and %o7. longjmp restores
the stack, and the callee-saved registers (all local/in registers: %i0-%i7, %l0-%l7)
using the stored %fp and register windows. However, this does not guarantee that the longjmp
will restore the registers, as they were when the setjmp was called. This is because these
registers may be clobbered after returning from setjmp, but before calling longjmp.

This patch prevents the registers %i0-%i5, %l0-l7 to live across the setjmp call using the register mask.  

llvm-svn: 190033

llvm-svn: 189981

llvm-svn: 189980

llvm-svn: 189979

These instructions, such as vmul.f32, require the second source operand to
be in D0-D15 rather than the full D0-D31. When optimizing, make sure to
account for that by constraining the register class of a replacement virtual
register to be compatible with the virtual register(s) it's replacing.

I've been unsuccessful in creating a non-fragile regression test. This issue
was detected by the LLVM nightly test suite running on an A15 (Bullet).

PR17093: http://llvm.org/bugs/show_bug.cgi?id=17093
llvm-svn: 189972

Unaligned vldm/vstm need more uops and therefore are slower in general on swift.

radar://14522102

llvm-svn: 189961

Fix scheduling for vldm/vstm instructions that load/store more than 32 bytes on Cortex-A9. This also makes the existing code more compact.

llvm-svn: 189958

  This assertion is triggered because an integer constant is created with wrong
  type.

llvm-svn: 189948

      sshr,ushr,ssra,usra,srshr,urshr,srsra,ursra,sri,shl,sli,sqshlu,sqshl,uqshl,shrn,sqrshrun,sqshrn,uqshr,sqrshrn,uqrshrn,sshll,ushll
 and 4 convert instructions:
      scvtf,ucvtf,fcvtzs,fcvtzu

llvm-svn: 189925

llvm-svn: 189912

Iterator of std::vector may be implemented as a raw pointer. In
this case begin iterators are rvalues and cannot be incremented.
For example, this is the case with STDCXX implementation of vector.

Patch by Konstantin Tokarev <annulen@yandex.ru>.

llvm-svn: 189911

Previously, the clang crash handling code would kick in and give a crash
report for these, even though they're not that sort of error.

rdar://14882264

llvm-svn: 189878

WIP: Refactor some code so that it can be called by more than just one method. No functionality change.

llvm-svn: 189849

This reverts commit r189648.

Fixes for the previously failing clang-side arm_neon_intrinsics test
cases will be checked in separately.

llvm-svn: 189841