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

llvm-svn: 165187

file name if building Apple-style.

llvm-svn: 165185

llvm-svn: 165182

This allows the processor-specific machine model to override selected
base opcodes without any fanciness.
e.g. InstRW<[CoreXWriteVANDP], (instregex "VANDP")>.

llvm-svn: 165180

A processor can now arbitrarily alias one SchedWrite onto
another. Only the SchedAlias definition need be within the processor
model. The aliased SchedWrite may be a SchedVariant, WriteSequence, or
transitively refer to another alias.

llvm-svn: 165179

llvm-svn: 165178

MSVC compiler.

llvm-svn: 165174

in the Intel syntax.

The MC layer supports emitting in the Intel syntax, but this would require the
inline assembly MachineInstr to be lowered to an MCInst before emission.  This
is potential future work, but for now emitting directly from the MachineInstr
suffices.

llvm-svn: 165173

for the number of bytes in a particular instruction
to using
   const MCInstrDesc &Desc = MCII.get(TmpInst.getOpcode());
   Desc.getSize()

This is necessary with the advent of 16 bit instructions with
mips16 and micromips. It is also puts Mips in compliance with
the other targets for getting instruction size.

llvm-svn: 165171

llvm-svn: 165168

llvm-svn: 165166

In order to avoid rev-lock with Clang when moving to the new API, also
preserve the current API temporarily and insert a shim to implement the
new API in terms of the old.

llvm-svn: 165165

llvm-svn: 165164

llvm-svn: 165163

multiple stores with a single load. We create the wide loads and stores (and their chains)
before we remove the scalar loads and stores and fix the DAG chain. We attempted to merge
loads with a different chain. When that happened, the assumption that it is safe to RAUW
broke and a cycle was introduced.

llvm-svn: 165148