llvm-svn: 128398

The reassignment phase was able to move interference with a higher spill weight,
but it didn't happen very often and it was fairly expensive.

The existing interference eviction picks up the slack.

llvm-svn: 128397

functionality changed.

llvm-svn: 128396

to be added... Sorry for the noise.

llvm-svn: 128395

and flesh out the existing uninitialized testing for field initializers.

The tests come from Richard's original patch, but I've cleaned them up
a bit and ordered them more naturally.

Also, I added a test for the most simple base case:
int x = x;

And it turns out we miss this one! =[ That and another bad FIXME on the
field initializer checking are left in the test.

llvm-svn: 128394

No change in functionality intended.

llvm-svn: 128393

functionality intended.

llvm-svn: 128392

functionality intended.

llvm-svn: 128391

required modifying a few tests that specifically use note include stacks
to check the source manager's view of include stacks. I've simply added
the flag to these tests for now, they may have to be more substantially
changed if we decide to remove support for note include stacks
altogether.

Also, add a test for include stacks on notes that was supposed to go in
with the previous commit.

llvm-svn: 128390

an objc method. Fixes // rdar://9181463

llvm-svn: 128389

the subclass optional data.

llvm-svn: 128388

Improve recovery (error + fix-it) when parsing type dependent template name without the "template" keyword.

For example:
   typename C1<T>:: /*template*/ Iterator<0> pos; 

Also the error is downgraded to an ExtWarn in Microsoft mode.

llvm-svn: 128387

CharUnits).

llvm-svn: 128386

functionality intended.

llvm-svn: 128385

CharUnits. No change in functionality intended.

llvm-svn: 128384

functionality intended.

llvm-svn: 128383

AltiVec vector comparison logic now affect only vectors of fundamental AltiVec vector types. It fixes bug 9347. 

llvm-svn: 128381

llvm-svn: 128380

Constant folding support for calls to umul.with.overflow(), basically identical to the smul.with.overflow() code.

llvm-svn: 128379

to have structured log files rather than one big file produced by
piping output.

llvm-svn: 128378

llvm-svn: 128377

This is basically the same idea as the warning on uninitialized uses of
fields within an initializer list. As such, it is on by default and
under -Wuninitialized.

Original patch by Richard Trieu, with some massaging from me on the
wording and grouping of the diagnostics.

llvm-svn: 128376

supported: AltiVec vector initialization with a single literal according to PIM section 2.5.1 - after initialization all elements have the value specified by the literal

llvm-svn: 128375

Emit them instead with the linkage of the VTT.

I'm actually really ambivalent about this;  it's what GCC does, but outside
of improving code size (if the linkage is coalescing), I'm not sure it's
at all relevant.  Construction vtables are naturally referenced only by the
VTT, which is itself only referenced by complete-object constructors and
destructors;  giving the construction vtables possibly-external linkage is
important if you have an optimization that drills through the VTT to a
reference to a particular construction vtable which it cannot just emit
itself.

llvm-svn: 128374

removes one use of X which helps it pass the many hasOneUse() checks.

In my analysis, this turns up very often where X = A >>exact B and that can't be
simplified unless X has one use (except by increasing the lifetime of A which is
generally a performance loss).

llvm-svn: 128373

llvm-svn: 128372

These stacks are often less important than those on primary diagnostics.

As the number of notes grows, this becomes increasingly important. The
include stack printing is clever and doesn't print stacks for adjacent
diagnostics from the same file, but when a note is in between a sequence
of errors in a header file, and the notes all refer to some other file,
we end up getting a worst-case ping-pong of include stacks that take up
a great deal of vertical space.

Still, for now, the default behavior isn't changed. We can evaluate user
feedback with the flag.

Patch by Richard Trieu, a couple of style tweaks from me.

llvm-svn: 128371

llvm-svn: 128370

default for -fwrapv if that flag isn't specified explicitly. We always
prefer an explict setting of -fwrapv when present. Also adds support for
-fno-wrapv to allow disabling -fwrapv even when -fno-strict-overflow is
passed.

llvm-svn: 128353

specifications within the global scope, from Elliot Glaysher.

llvm-svn: 128352

The main register class may have been inflated by live range splitting, so that
register class is not necessarily valid for the snippet instructions.

Use the original register class for the stack slot interval.

llvm-svn: 128351

llvm-svn: 128350

llvm-svn: 128349

from an objective-c message: // rdar://9005189

llvm-svn: 128348

an architecture into ArchSpec:

uint32_t
ArchSpec::GetMinimumOpcodeByteSize() const;

uint32_t
ArchSpec::GetMaximumOpcodeByteSize() const;

Added an AddressClass to the Instruction class in Disassembler.h.
This allows decoded instructions to know know if they are code,
code with alternate ISA (thumb), or even data which can be mixed
into code. The instruction does have an address, but it is a good
idea to cache this value so we don't have to look it up more than 
once.

Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't
getting set.

Changed:

	bool
	SymbolContextList::AppendIfUnique (const SymbolContext& sc);

To:
	bool
	SymbolContextList::AppendIfUnique (const SymbolContext& sc, 
									   bool merge_symbol_into_function);

This function was typically being used when looking up functions
and symbols. Now if you lookup a function, then find the symbol,
they can be merged into the same symbol context and not cause
multiple symbol contexts to appear in a symbol context list that
describes the same function.

Fixed the SymbolContext not equal operator which was causing mixed
mode disassembly to not work ("disassembler --mixed --name main").

Modified the disassembler classes to know about the fact we know,
for a given architecture, what the min and max opcode byte sizes
are. The InstructionList class was modified to return the max
opcode byte size for all of the instructions in its list.
These two fixes means when disassemble a list of instructions and dump 
them and show the opcode bytes, we can format the output more 
intelligently when showing opcode bytes. This affects any architectures
that have varying opcode byte sizes (x86_64 and i386). Knowing the max
opcode byte size also helps us to be able to disassemble N instructions
without having to re-read data if we didn't read enough bytes.

Added the ability to set the architecture for the disassemble command.
This means you can easily cross disassemble data for any supported 
architecture. I also added the ability to specify "thumb" as an 
architecture so that we can force disassembly into thumb mode when
needed. In GDB this was done using a hack of specifying an odd
address when disassembling. I don't want to repeat this hack in LLDB,
so the auto detection between ARM and thumb is failing, just specify
thumb when disassembling:

(lldb) disassemble --arch thumb --name main

You can also have data in say an x86_64 file executable and disassemble
data as any other supported architecture:
% lldb a.out
Current executable set to 'a.out' (x86_64).
(lldb) b main
(lldb) run
(lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes
0x100001080:  0xb580 push   {r7, lr}
0x100001082:  0xaf00 add    r7, sp, #0

Fixed Target::ReadMemory(...) to be able to deal with Address argument object
that isn't section offset. When an address object was supplied that was
out on the heap or stack, target read memory would fail. Disassembly uses
Target::ReadMemory(...), and the example above where we disassembler thumb
opcodes in an x86 binary was failing do to this bug.

llvm-svn: 128347

llvm-svn: 128346

fix the second part of rdar://8366474 - clang fails to parse ObjC selectors with '::', when :: isn't the first part of the selector.

llvm-svn: 128344

llvm-svn: 128343

It couldn't be used outside of the file because SDISelAsmOperandInfo
is local to SelectionDAGBuilder.cpp. Making it a static function avoids
a weird linkage dance.

llvm-svn: 128342

Tested that MinGW/MSYS builds fine without that.

llvm-svn: 128341