llvm-svn: 143529

Narrowest possible fix for PR11279.

llvm-svn: 143522

it is separating the directory part from the basename of the FileName.  Noticed 
that this:

  .file 1 "dir/foo"

when assembled got the two parts switched.  Using the Mac OS X dwarfdump tool
it can be seen easily:

% dwarfdump -a a.out
include_directories[  1] = 'foo'
                Dir  Mod Time   File Len   File Name
                ---- ---------- ---------- ---------------------------
file_names[  1]    1 0x00000000 0x00000000 dir
...

Which should be:
...
include_directories[  1] = 'dir'
                Dir  Mod Time   File Len   File Name
                ---- ---------- ---------- ---------------------------
file_names[  1]    1 0x00000000 0x00000000 foo

llvm-svn: 143521

llvm-svn: 143507

Teach the x86 backend a couple tricks for dealing with v16i8 sra by a constant splat value.  Fixes PR11289.

llvm-svn: 143498

This can happen if the address + addend is less than the start of the cp / dp.

llvm-svn: 143459

llvm-svn: 143458

llvm-svn: 143457

llvm-svn: 143455

Make sure we use the right insertion point when instcombine replaces a PHI with another instruction.  (Specifically, don't insert an arbitrary instruction before a PHI.)  Fixes PR11275.

llvm-svn: 143437

llvm-svn: 143424

llvm-svn: 143421

llvm-svn: 143420

llvm-svn: 143404

llvm-svn: 143400

llvm-svn: 143352

llvm-svn: 143351

llvm-svn: 143336

llvm-svn: 143332

llvm-svn: 143331

-enable-dwarf-directory.

llvm-svn: 143326

with the given predicate, it matches any condition and returns the
predicate - d'oh!  Original commit message:
The expression icmp eq (select (icmp eq x, 0), 1, x), 0 folds to false.
Spotted by my super-optimizer in 186.crafty and 450.soplex.  We really
need a proper infrastructure for handling generalizations of this kind
of thing (which occur a lot), however this case is so simple that I decided
to go ahead and implement it directly.

llvm-svn: 143318

X86: Emit logical shift by constant splat of <16 x i8> as a <8 x i16> shift and zero out the bits where zeros should've been shifted in.

llvm-svn: 143315

Fix return type for X86 mpsadbw instrinsic. The instruction takes in a vector of 8-bit integers, but produces a vector of 16-bit integers.

llvm-svn: 143313

Fix pr11266.

On x86: (shl V, 1) -> add V,V

Hardware support for vector-shift is sparse and in many cases we scalarize the
result. Additionally, on sandybridge padd is faster than shl.

llvm-svn: 143311

llvm-svn: 143307

If all of the inputs are zero/any_extended, create a new simple BV
which can be further optimized by other BV optimizations.

llvm-svn: 143297

llvm-svn: 143291

SimplifyLibCalls: Use IRBuilder.CreateGlobalString when creating a string for printf->puts, which correctly sets the unnamed_addr bit on the resulting GlobalVariable.

Fixes PR11264.

llvm-svn: 143289

llvm-svn: 143265

llvm-svn: 143262

llvm-svn: 143247

When '~imm' is encodable as a t2_so_imm but plain 'imm' is not. For example,
  mov r2, #-3
becomes
  mvn r2, #2

rdar://10349224

llvm-svn: 143235

llvm-svn: 143231

Spotted by my super-optimizer in 186.crafty and 450.soplex.  We really
need a proper infrastructure for handling generalizations of this kind
of thing (which occur a lot), however this case is so simple that I decided
to go ahead and implement it directly.

llvm-svn: 143214

For completeness - not spotted in the wild.

llvm-svn: 143211

in 186.crafty.

llvm-svn: 143209

Reapply r143202, with a manual decoding hook for SWP.  This change inadvertantly exposed a decoding ambiguity between SWP and CPS that the auto-generated decoder can't handle.

llvm-svn: 143208

fixes: Use a separate register, instead of SP, as the
calling-convention resource, to avoid spurious conflicts with
actual uses of SP. Also, fix unscheduling of calling sequences,
which can be triggered by pseudo-two-address dependencies.

llvm-svn: 143206

Outside an IT block, "add r3, #2" should select a 32-bit wide encoding
rather than generating an error indicating the 16-bit encoding is only
legal in an IT block (outside, the 'S' suffic is required for the 16-bit
encoding).

rdar://10348481

llvm-svn: 143201