attribute.

Part of rdar://problem/8595231

llvm-svn: 117526

llvm-svn: 117525

is that we need more information to decide the exact conditions for whether
one ObjCObjectPointer is an acceptable return/parameter override for another,
so we're going to disable that entire class of warning for now.  The
"forward developement" warning category, -Wmethod-signatures, can receive
unrestricted feature work, and when we're happy with how it acts, we'll
turn it on by default.

This is a pretty conservative change, and nobody's totally content with it.

llvm-svn: 117524

doesn't mean that you can't get a .o file.  Apparently
this is confusing :)

llvm-svn: 117523

llvm-svn: 117522

Don't warn about unamed bitfield ivars in the ObjCUnusedIvarsChecker.  Fixes <rdar://problem/8481311>.

llvm-svn: 117521

llvm-svn: 117520

- For now, loads of [r, r] addressing mode is the same as the
  [r, r lsl/lsr/asr #] variants. ARMBaseInstrInfo::getOperandLatency() should
  identify the former case and reduce the output latency by 1.
- Also identify [r, r << 2] case. This special form of shifter addressing mode
  is "free".

llvm-svn: 117519

by the number of defs first for it to match the instruction itinerary.

llvm-svn: 117518

llvm-svn: 117517

variables by name. It was accidentally getting all the globals
for the compile unit that contained the global variable named
NAME.

llvm-svn: 117516

llvm-svn: 117515

Bruno, please review, but I'm pretty sure this is right.
Patch by Alex Mac!

llvm-svn: 117514

llvm-svn: 117513

llvm-svn: 117512

llvm-svn: 117511

llvm-svn: 117510

complex load / store addressing mode) when they have higher cost and
when they have more than one use.

llvm-svn: 117509

No aliasing is needed, these work as given in the BE.

llvm-svn: 117508

Radar 8595129

llvm-svn: 117507

Putting r117193 back except for the compile time cost. Rather than assuming fallthroughs uses all registers, just gather the union of all successor liveins.

llvm-svn: 117506

the LDR instructions have. This makes the literal/register forms of the
instructions explicit and allows us to assign scheduling itineraries
appropriately. rdar://8477752

llvm-svn: 117505

small tweaks to reflect statements of what really ever shipped.  ABI is, and has been, accurate for what we ship.

llvm-svn: 117504

llvm-svn: 117503

llvm-svn: 117502

for specifying fractional bits for fixed point conversions.

llvm-svn: 117501

type-based visibility.

llvm-svn: 117500

not loading the specializations of a class template until some AST
consumer needs them.

llvm-svn: 117498

llvm-svn: 117497

llvm-svn: 117496

llvm-svn: 117495

llvm-svn: 117494

disabled.

llvm-svn: 117493

reconcile missing typos & delete obsolete pre-SnowLeopard section w.r.t. prior repository for this document

llvm-svn: 117492

aggressive about the form we expect bools to be in.  I don't really have
time to fix all the sources right now.

llvm-svn: 117486

llvm-svn: 117485

// rdar: // 8600553.

llvm-svn: 117484

llvm-svn: 117483

elements than the result vector type.  So, when an instruction like:

%8 = shufflevector <2 x float> %4, <2 x float> %7, <4 x i32> <i32 1, i32 0, i32 3, i32 2>

is translated to a DAG, each operand is changed to a concat_vectors node that appends 2 undef elements.  That is:

shuffle [a,b], [c,d] is changed to:
shuffle [a,b,u,u], [c,d,u,u]

That's probably the right thing for x86 but for NEON, we'd much rather have:

shuffle [a,b,c,d], undef

Teach the DAG combiner how to do that transformation for ARM.  Radar 8597007.

llvm-svn: 117482

llvm-svn: 117481