llvm-svn: 117405

llvm-svn: 117404

in IR gen, and use those to fix a correctness issue with bool atomic
intrinsics.  rdar://problem/8461234

llvm-svn: 117403

llvm-svn: 117402

llvm-svn: 117401

llvm-svn: 117400

llvm-svn: 117399

llvm-svn: 117398

different ways. Check once, and use an assert to handle
consistency checking.

llvm-svn: 117397

llvm-svn: 117396

llvm-svn: 117395

llvm-svn: 117394

doesn't need its return value.

llvm-svn: 117393

SlotIndexes when available.

llvm-svn: 117392

llvm-svn: 117391

llvm-svn: 117390

llvm-svn: 117389

llvm-svn: 117388

llvm-svn: 117387

so that it's done in one place.

llvm-svn: 117386

llvm-svn: 117385

llvm-svn: 117384

causing modules that haven't already been parsed from being searched.

llvm-svn: 117383

llvm-svn: 117382

llvm-svn: 117381

llvm-svn: 117380

llvm-svn: 117378

llvm-svn: 117377

s/endScope/endInstruction/g

llvm-svn: 117376

llvm-svn: 117374

llvm-svn: 117373

typo. This can happen with context-sensitive keywords like "super",
when typo correction didn't know that "super" wasn't permitted in this
context.

llvm-svn: 117372

Magic is happening that we don't understand.

llvm-svn: 117370

on RIP relative relocations looks artificial, but this is a superset of
what we were able to do before.

llvm-svn: 117364

llvm-svn: 117362

loaded/parsed.  Should add timers to this eventually.

Delay getting a full UnwindPlan if it's possible to unwind with
just a fast UnwindPlan.  This keeps us from reading the eh_frame
section unless we hit something built -fomit-frame pointer or we
hit a frame with no symbol (read: no start address) available.

It doesn't look like it is correctly falling back to using the
full UnwindPlan to provide additional registers that the fast
UnwindPlan doesn't supply; e.g. go to the middle of a stack and
ask for r12 and it will show you the value of r12 in frame 0.
That's a bug for tomorrow.

llvm-svn: 117361

The SPU ABI does not mention v64, and all examples
in C suggest v128 are treated similarily to arrays, 
we use array alignment for v64 too. This makes the 
alignment of e.g. [2 x <2 x i32>] behave "intuitively"
and similar to as if the elements were e.g. i32s.

This also makes an "unaligned store" test to be 
aligned, with different (but functionally equivalent)
code generated.

llvm-svn: 117360

There's probably still significant padding waste on x86-64 UNIXen, but
the difference in 32-bit compiles should be significant.

There are a lot of Expr nodes left that could lose a word this way.

llvm-svn: 117359

anymore.

llvm-svn: 117357

llvm-svn: 117356