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

crtfastmath.o contains routines to set the floating point flags to a faster,
unsafe mode. Linking it in speeds up code dealing with denormals significantly
(PR14024).

For now this is only enabled on linux where I can test it and crtfastmath.o is
widely available. We may want to provide a similar file with compiler-rt
eventually and/or enable it on other platforms too.

llvm-svn: 165240

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

For GNU attributes, instead of reusing attribute source 
location for the scope location, use SourceLocation() since 
GNU attributes don not have scope tokens. 

llvm-svn: 165234

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

llvm-svn: 165231

llvm-svn: 165229

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

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