Also clean up the arguments to all the MOVCC instructions so the
operands always are (true-val, false-val, cond-code).

llvm-svn: 182221

llvm-svn: 182220

[Sparc] Rearrange integer registers' allocation order so that register allocator will use I and G registers before using L and O registers.

Also, enable registers %g2-%g4 to be used in application and %g5 in 64 bit mode.

llvm-svn: 182219

llvm-svn: 182217

llvm-svn: 182216

AArch64 ELF uses .rela relocations so there's no need to actually make
use of the bits we're setting in the destination  However, we should
make sure all bits are cleared properly since multiple runs of
resolveRelocations are possible and these could combine to produce
invalid results if stale versions remain in the code.

llvm-svn: 182214

lli's remote MCJIT code calls setExecutable just prior to running
code. In line with Darwin behaviour this seems to be the place to
invalidate any caches needed so that relocations can take effect
properly.

llvm-svn: 182213

llvm-svn: 182212

llvm-svn: 182211

On 32-bit hosts %p can print garbage when given a uint64_t, we should
use %llx instead. This only affects the output of the debugging text
produced by lli.

llvm-svn: 182209

llvm-svn: 182201

This is useful if something that looks like (x & (1 << y)) ? 64 : 32 is
the divisor in a modulo operation.

llvm-svn: 182200

We might encouter single edge PHIs - handle them with an identity select.

Fixes PR15990.

llvm-svn: 182199

Patch by Yacine Belkadi.

llvm-svn: 182197

Should help the ppc32 buildbot.

llvm-svn: 182194

We don't need to reject all inline asm as using the counter register (most does
not). Only those that explicitly clobber the counter register need to prevent
the transformation.

llvm-svn: 182191

llvm-svn: 182190

The peephole tries to reorder MOV32r0 instructions such that they are
before the instruction that modifies EFLAGS.

The problem is that the peephole does not consider the case where the
instruction that modifies EFLAGS also depends on the previous state of
EFLAGS.

Instead, walk backwards until we find an instruction that has a def for
EFLAGS but does not have a use.
If we find such an instruction, insert the MOV32r0 before it.
If it cannot find such an instruction, skip the optimization.

llvm-svn: 182184

The same comment is already made in the header

llvm-svn: 182181

llvm-svn: 182180

This patch matches GCC behavior: the code used to only allow unaligned
load/store on ARM for v6+ Darwin, it will now allow unaligned load/store
for v6+ Darwin as well as for v7+ on Linux and NaCl.

The distinction is made because v6 doesn't guarantee support (but LLVM
assumes that Apple controls hardware+kernel and therefore have
conformant v6 CPUs), whereas v7 does provide this guarantee (and
Linux/NaCl behave sanely).

The patch keeps the -arm-strict-align command line option, and adds
-arm-no-strict-align. They behave similarly to GCC's -mstrict-align and
-mnostrict-align.

I originally encountered this discrepancy in FastIsel tests which expect
unaligned load/store generation. Overall this should slightly improve
performance in most cases because of reduced I$ pressure.

llvm-svn: 182175

llvm-svn: 182172

llvm-svn: 182169

The errors were:

non-constant-expression cannot be narrowed from type 'int64_t' (aka 'long') to 'uint32_t' (aka 'unsigned int') in initializer list

and

non-constant-expression cannot be narrowed from type 'long' to 'uint32_t' (aka 'unsigned int') in initializer list

llvm-svn: 182168

Use EVT::changeExtendedVectorElementTypeToInteger instead of doing the
same thing that it does

llvm-svn: 182165

llvm-svn: 182164

Patch by Mark Seaborn.

llvm-svn: 182131

It solves a bug uncovered by dot4 patch where the register class of
int_load_input use was ignored.

llvm-svn: 182130

llvm-svn: 182129

It should increase PV substitution opportunities and lower gpr
usage (pending computations path are "flushed" sooner)

llvm-svn: 182128

llvm-svn: 182127

Dot4 now uses 8 scalar operands instead of 2 vectors one which allows register
coalescer to remove some unneeded COPY.
This patch also defines some structures/functions that can be used to handle
every vector instructions (CUBE, Cayman special instructions...) in a similar
fashion.

llvm-svn: 182126

llvm-svn: 182125

Almost all instructions that takes a 128 bits reg as input (fetch, export...)
have the abilities to swizzle their argument and output. Instead of printing
default swizzle for each 128 bits reg, rename T*.XYZW to T* and let instructions
print potentially optimized swizzles themselves.

llvm-svn: 182124

llvm-svn: 182123

llvm-svn: 182122

llvm-svn: 182121

Reviewed-by: Vincent Lejeune <vljn@ovi.com>

https://bugs.freedesktop.org/show_bug.cgi?id=64193
https://bugs.freedesktop.org/show_bug.cgi?id=64257
https://bugs.freedesktop.org/show_bug.cgi?id=64320

NOTE: This is a candidate for the 3.3 branch.
llvm-svn: 182113

llvm-svn: 182112

 This is to generate correct framesetup code when the function
 has variable sized allocas.

llvm-svn: 182108