a) frame setup instructions define the prologue
b) we shouldn't change our location mid-stream

Add a test to make sure that the stack adjustment stays within
the prologue.

llvm-svn: 165250

llvm-svn: 165249

Patch by Daniel Malea.

llvm-svn: 165246

llvm-svn: 165244

llvm-svn: 165243

llvm-svn: 165242

- Add 'HwEncoding' for X86 registers and call getEncodingValue() to
  retrieve their encoding values.
- This's the first step to adopt new scheme. Furthur revising is onging.

llvm-svn: 165241

llvm-svn: 165239

llvm-svn: 165238

- add tokens to PPCInstrInfo.td and PPCInstr64Bit.td to resolve
"Instruction 'foo' has no tokens" errors during llvm-tblgen
-gen-asm-matcher attempts.  At this time, the added
tokens are "#comment" style rather than the actual mnemonic.  This will
be revisited once the rest of the base asmparser bits get straightened
out for ppc64-elf-linux.

llvm-svn: 165237

Not all targets have itineraries, but the subtarget always has an
MCSchedModel.

llvm-svn: 165236

llvm-svn: 165235

llvm-svn: 165233

SimplifyCFG: Enhance the "remove CFG edge that leads to null pointer dereference" optimization to also handle instructions with multiple uses.

We conservatively only check the first use to avoid walking long use chains.
This catches the common case of having both a load and a store to a pointer
supplied by a PHI node.

llvm-svn: 165232

cpyDest can be mutated in some cases, which would then cause a crash later if
indeed the memory was underaligned.  This brought down several buildbots, so
I guess the underaligned case is much more common than I thought!

llvm-svn: 165228

alignment of the return type.  Teach the optimizers this.

llvm-svn: 165226

llvm-svn: 165225

llvm-svn: 165224

Currently, we re-visit allocas when something changes about the way they
might be *split* to allow better scalarization to take place. However,
we weren't handling the case when the *promotion* is what would change
the behavior of SROA. When an address derived from an alloca is stored
into another alloca, we consider the first to have escaped. If the
second is ever promoted to an SSA value, we will suddenly be able to run
the SROA pass on the first alloca.

This patch adds explicit support for this form if iteration. When we
detect a store of a pointer derived from an alloca, we flag the
underlying alloca for reprocessing after promotion. The logic works hard
to only do this when there is definitely going to be promotion and it
might remove impediments to the analysis of the alloca.

Thanks to Nick for the great test case and Benjamin for some sanity
check review.

llvm-svn: 165223

was less aligned than the old.  In the testcase this results in an overaligned
memset: the memset alignment was correct for the original memory but is too much
for the new memory.  Fix this by either increasing the alignment of the new
memory or bailing out if that isn't possible.  Should fix the gcc-4.7 self-host
buildbot failure.

llvm-svn: 165220

Sorry for this being broken so long. =/

As part of this, switch all of the existing tests to be Little Endian,
which is the behavior I was asserting in them anyways! Add in a new
big-endian test that checks the interesting behavior there.

Another part of this is to tighten the rules abotu when we perform the
full-integer promotion. This logic now rejects cases where there fully
promoted integer is a non-multiple-of-8 bitwidth or cases where the
loads or stores touch bits which are in the allocated space of the
alloca but are not loaded or stored when accessing the integer. Sadly,
these aren't really observable today as the rest of the pass will
already ensure the invariants hold. However, the latter situation is
likely to become a potential concern in the future.

Thanks to Benjamin and Duncan for early review of this patch. I'm still
looking into whether there are further endianness issues, please let me
know if anyone sees BE failures persisting past this.

llvm-svn: 165219

llvm-svn: 165213

llvm-svn: 165212

llvm-svn: 165211

llvm-svn: 165210

llvm-svn: 165209

llvm-svn: 165208

llvm-svn: 165207

llvm-svn: 165206

llvm-svn: 165205

llvm-svn: 165204

llvm-svn: 165203

allocator. Fixes PR13945.

llvm-svn: 165201

llvm-svn: 165200

macro instruction (li) in the assembler.

We have identified three possible expansions depending on 
the size of immediate operand:
  1) for 0 ≤ j ≤ 65535.
     li d,j =>
     ori d,$zero,j

  2) for −32768 ≤ j < 0.
     li d,j =>
     addiu d,$zero,j

  3) for any other value of j that is representable as a 32-bit integer.
     li d,j =>
     lui d,hi16(j)
     ori d,d,lo16(j)

All of the above have been implemented in ths patch.

Contributer: Vladimir Medic
llvm-svn: 165199

llvm-svn: 165198

This patch is a partial implementation of mips .set assembler directive. Directive is defined as follows:
.set option
The patch implements following options

    at - lets the assembler use the $at register for macros,
         but generates warnings if the source program uses $at

    noat - let source programs use $at without issuingwarnings.

    noreorder - prevents the assembler from reordering machine 
                language instructions.
    nomacro - causes the assembler to print a warning whenever 
              an assembler operation generates more than one 
              machine language instruction.
    macro - lets the assembler generate multiple machine instructions 
            from a single assembler instruction
    reorder - lets the assembler reorder machine language 
               instructions to improve performance

The above variants are parsed and their boolean values set or unset.
The code to actually use them will come later.

Following options are not implemented yet:

nomips16
nomicromips
move
nomove

Contributer: Vladimir Medic
llvm-svn: 165194

llvm-svn: 165190

When aliasing tools, rather than using the base TOOLEXENAME, we should
instead use the built tool's basename (for 'make') or the installed
tool's basename (for 'make install').

This should not cause any changes for anyone building unprefixed 'clang'
and 'clang++' tools.

Patch by Rick Foos!

llvm-svn: 165189

llvm-svn: 165188