Fixes http://code.google.com/p/address-sanitizer/issues/detail?id=117.

llvm-svn: 165227

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

llvm-svn: 165222

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: 165218

This may be slightly more efficient and is definitely more readable.

llvm-svn: 165217

llvm-svn: 165216

Fix r165005: The lexical DeclContext is not the right place to make a decision about whether we need to call tryAddTopLevelDecl or not. That call should be made when the DeclContext's redeclaration context is the translation unit.

llvm-svn: 165215

llvm-svn: 165214

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

llvm-svn: 165202

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

up being contracted during codegen.

llvm-svn: 165197

llvm-svn: 165196

mess by handling all pragmas which the parser touches uniformly.
<rdar://problem/12248901>, etc.

llvm-svn: 165195

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

ProcessGDBRemote and DynamicLoaderDarwinKernel and a patch was needed
to get this building on Linux.  Thanks!

llvm-svn: 165193

llvm-svn: 165192

/Users/void/llvm/llvm-tot.src/projects/compiler-rt/lib/arm/eqdf2vfp.S:22:2: error: instruction requires: VFP2
 vmov d6, r0, r1
 ^
/Users/void/llvm/llvm-tot.src/projects/compiler-rt/lib/arm/eqdf2vfp.S:23:2: error: instruction requires: VFP2
 vmov d7, r2, r3
 ^
/Users/void/llvm/llvm-tot.src/projects/compiler-rt/lib/arm/eqdf2vfp.S:24:2: error: instruction requires: VFP2
 vcmp.f64 d6, d7
 ^
/Users/void/llvm/llvm-tot.src/projects/compiler-rt/lib/arm/eqdf2vfp.S:25:2: error: instruction requires: VFP2
 vmrs apsr_nzcv, fpscr
 ^

llvm-svn: 165191

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