llvm-svn: 189195

llvm-svn: 189189

I need to add the rest of these to the list or else to delay putting
out the actual stub until later in code generation when I know if
the external function ever got emitted

Resubmit this patch. The target triple needs to be added to the test so that 
clang does not tell the backend the wrong target when the host is BSD. There
is a clang bug in here somewhere that I need to track down. At Mips this
has been filed internally as a bug.

llvm-svn: 189186

Add hasSideEffects/mayLoad/mayStore flags to the X86 moffs8/moffs16/moffs32/moffs64 versions of move.

llvm-svn: 189182

llvm-svn: 189178

llvm-svn: 189176

I need to add the rest of these to the list or else to delay putting
out the actual stub until later in code generation when I know if
the external function ever got emitted.

llvm-svn: 189161

This support was removed by accident during the MC conversion

llvm-svn: 189160

There is no advantage in being different and using the same names simplifies
clang a bit.

llvm-svn: 189141

llvm-svn: 189111

llvm-svn: 189109

llvm-svn: 189103

This function attribute indicates that the function is not optimized
by any optimization or code generator passes with the 
exception of interprocedural optimization passes.

llvm-svn: 189101

Just the instructions and intrinsics for now.

llvm-svn: 189100

This allows us to make more use of the many compare reg,mem instructions.

llvm-svn: 189099

If we had a store of an integer to memory, and the integer and store size
were suitable for a form of MV..., we used MV... no matter what.  We could
then have sequences like:

    lay %r2, 0(%r3,%r4)
    mvi 0(%r2), 4

In these cases it seems better to force the constant into a register
and use a normal store:

    lhi %r2, 4
    stc %r2, 0(%r3, %r4)

since %r2 is more likely to be hoisted and is easier to rematerialize.

llvm-svn: 189098

...so that it can be used for z too.  Most of the code is the same.
The only real change is to use TargetTransformInfo to test when a sqrt
instruction is available.

The pass is opt-in because at the moment it only handles sqrt.

llvm-svn: 189097

I'd forgotten that "Requires" blocks override rather than add to the
constraints, so my pseudo-instruction was being selected in Thumb mode leading
to nonsense instructions.

rdar://problem/14817358

llvm-svn: 189096

llvm-svn: 189095

llvm-svn: 189085

This field specifies registers that are preserved across function calls,
but that should not be included in the generates SaveList array.

This can be used ot generate regmasks for architectures that save
registers through other means, like SPARC's register windows.

llvm-svn: 189084

This fixes a crash in Unigine Tropics.

https://bugs.freedesktop.org/show_bug.cgi?id=68389

llvm-svn: 189057

This uses the ARMcmov pattern that Tim cleaned up in r188995.

Thanks to Simon Tatham for his floating point help!

llvm-svn: 189024

The instruction to convert between floating point and fixed point representations
takes an immediate operand for the number of fractional bits of the fixed point
value. ARMARM specifies that when that number of bits is zero, the assembler
should encode floating point/integer conversion instructions. 

This patch adds the necessary instruction aliases to achieve this behaviour.

llvm-svn: 189009

we pass these tests with -verify-machineinstrs.

llvm-svn: 189006

llvm-svn: 189005

The function call to external function should come with PLT relocation
type if the PIC relocation model is used.

llvm-svn: 189002

Back in the mists of time (2008), it seems TableGen couldn't handle the
patterns necessary to match ARM's CMOV node that we convert select operations
to, so we wrote a lot of fairly hairy C++ to do it for us.

TableGen can deal with it now: there were a few minor differences to CodeGen
(see tests), but nothing obviously worse that I could see, so we should
probably address anything that *does* come up in a localised manner.

llvm-svn: 188995

The code for 'Q' and 'R' operand modifiers needs to look through tied
operands to discover the register class.

llvm-svn: 188990

Indirect tail-calls shouldn't use R9 for the branch destination, as
it's not reliably a call-clobbered register.

rdar://14793425

llvm-svn: 188967

Spotted by Bill Wendling.

llvm-svn: 188942

Also obsessively reorder the headers to be in something closer to alphabetical order.

llvm-svn: 188928

        def imm0_63 : Operand<i32>, ImmLeaf<i32, [{ return Imm >= 0 && Imm < 63;}]>{
As it seems Imm <63 should be Imm <= 63. ImmLeaf is used in pattern match, but there is already a function check the shift amount range, so just remove ImmLeaf. Also add a test to check 63.

llvm-svn: 188911

According to the ARM specification, "mov" is a valid mnemonic for all Thumb2 MOV encodings.
To achieve this, the patch adds one instruction alias with a special range condition to avoid collision with the Thumb1 MOV.

llvm-svn: 188901

llvm-svn: 188899

The initial port used MLG(R) for i64 UMUL_LOHI but left the other three
combinations as not-legal-or-custom.  Although 32x32->{32,32}
multiplications exist, they're not as quick as doing a normal 64-bit
multiplication, so it didn't seem like i32 SMUL_LOHI and UMUL_LOHI
would be useful.  There's also no direct instruction for i64 SMUL_LOHI,
so it needs to be implemented in terms of UMUL_LOHI.

However, not defining these patterns means that we don't convert
division by a constant into multiplication, so this patch fills
in the other cases.  The new i64 SMUL_LOHI sequence is simpler
than the one that we used previously for 64x64->128 multiplication,
so int-mul-08.ll now tests the full sequence.

llvm-svn: 188898

I accidentally changed the encoding of the MSA registers to zero instead of 0
to 31. This change restores the encoding the registers had prior to r188893.

This didn't show up in the existing tests because direct-object emission isn't
implemented yet for MSA.

llvm-svn: 188896

llvm-svn: 188895

These are extensions of the existing FI[EDX]BR instructions, but use a spare
bit to suppress inexact conditions.

llvm-svn: 188894

No functional change

llvm-svn: 188893