llvm-svn: 26272

llvm-svn: 26260

llvm-svn: 26259

and SUBE nodes that actually expose what's going on and allow for
significant simplifications in the targets.

llvm-svn: 26255

llvm-svn: 26253

llvm-svn: 26252

llvm-svn: 26250

llvm-svn: 26249

issue. Need to do more experiments.

llvm-svn: 26247

llvm-svn: 26246

llvm-svn: 26245

llvm-svn: 26244

other small targets that do that can be learned from.  They also have
the added advantage of being tested :)

llvm-svn: 26243

   proves to be worth 20% on Ptrdist/ks. Might be related to dependency
   breaking support.
2. Added FsMOVAPSrr and FsMOVAPDrr as aliases to MOVAPSrr and MOVAPDrr. These
   are used for FR32 / FR64 reg-to-reg copies.
3. Tell reg-allocator to generate MOVSSrm / MOVSDrm and MOVSSmr / MOVSDmr to
   spill / restore FsMOVAPSrr and FsMOVAPDrr.

llvm-svn: 26241

llvm-svn: 26240

and ComputeMaskedBits to match the new improved versions in instcombine.
Tested against all of multisource/benchmarks on ppc.

llvm-svn: 26238

llvm-svn: 26234

distinguish between objects and register names, now we can have stuff
with names like "f84", "in6" etc etc.

this should fix one or two tests

llvm-svn: 26232

We do not want to emit "Loop: ... brcond Out; br Loop", as it adds an extra
instruction in the loop.  Instead, invert the condition and emit
"Loop: ... br!cond Loop; br Out.

Generalize the fix by moving it from PPCDAGToDAGISel to SelectionDAGLowering.

llvm-svn: 26231

transfer.

According to the Intel P4 Optimization Manual:

Moves that write a portion of a register can introduce unwanted
dependences. The movsd reg, reg instruction writes only the bottom
64 bits of a register, not to all 128 bits. This introduces a dependence on
the preceding instruction that produces the upper 64 bits (even if those
bits are not longer wanted). The dependence inhibits register renaming,
and thereby reduces parallelism.

Not to mention movaps is shorter than movss.

llvm-svn: 26226

Turns them into calls to memset / memcpy if 1) buffer(s) are not DWORD aligned,
2) size is not known to be greater or equal to some minimum value (currently 128).

llvm-svn: 26224

llvm-svn: 26222

llvm-svn: 26217

it, because this:

.bss
X:
.byte 0

results in the assembler warning: "initialization in bss segment".  Annoying.

llvm-svn: 26204

The ABI specifies that there is a register save area at the bottom of the
stack, which means the actual used pointer needs to be an offset from
the subtracted value.

llvm-svn: 26202

llvm-svn: 26197

llvm-svn: 26196

llvm-svn: 26193

llvm-svn: 26192

llvm-svn: 26186

emit it (instead of .space), saving a bit of space in the .o file.

For example:
int foo[100];
int bar[100] = {};

when compiled with C++ or -fno-common results in shrinkage from 1160 to 360
bytes of space.  The X86 backend can also do this on darwin.

llvm-svn: 26185

llvm-svn: 26183

XMM registers were not being handled.

llvm-svn: 26182

llvm-svn: 26181

llvm-svn: 26180

llvm-svn: 26179

llvm-svn: 26174

llvm-svn: 26173

maxStoresPerMemMove. Although the last one is not used.

llvm-svn: 26172

llvm-svn: 26169