second algorithm, but only loosely. It is more heavily based on the last
discussion I had with Andy. It continues to walk from the inner-most
loop outward, but there is a key difference. With this algorithm we
ensure that as we visit each loop, the entire loop is merged into
a single chain. At the end, the entire function is treated as a "loop",
and merged into a single chain. This chain forms the desired sequence of
blocks within the function. Switching to a single algorithm removes my
biggest problem with the previous approaches -- they had different
behavior depending on which system triggered the layout. Now there is
exactly one algorithm and one basis for the decision making.

The other key difference is how the chain is formed. This is based
heavily on the idea Andy mentioned of keeping a worklist of blocks that
are viable layout successors based on the CFG. Having this set allows us
to consistently select the best layout successor for each block. It is
expensive though.

The code here remains very rough. There is a lot that needs to be done
to clean up the code, and to make the runtime cost of this pass much
lower. Very much WIP, but this was a giant chunk of code and I'd rather
folks see it sooner than later. Everything remains behind a flag of
course.

I've added a couple of tests to exercise the issues that this iteration
was motivated by: loop structure preservation. I've also fixed one test
that was exhibiting the broken behavior of the previous version.

llvm-svn: 144495

The order in which the predicate is added differs between Thumb and ARM mode.  Fix predicate when in ARM mode and restore SelectIntrinsicCall.

llvm-svn: 144494

Fixed an issues with the SBType and SBTypeMember classes:
- Fixed SBType to be able to dump itself from python
- Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces
- Fixed SBTypeMember to be able to dump itself from python
- Fixed the SBTypeMember ability to get a field offset in bytes (the value
  being returned was wrong)
- Added the SBTypeMember ability to get a field offset in bits


Cleaned up a lot of the Stream usage in the SB API files.

llvm-svn: 144493

llvm-svn: 144492

A long time ago we started to centralized the STDOUT in lldb_private::Process
but we missed a few things still in ProcessGDBRemote.

llvm-svn: 144491

llvm-svn: 144490

This is the actual fix for the above radar where global variables that weren't
initialized were not being shown correctly when leaving the DWARF in the .o 
files. Global variables that aren't intialized have symbols in the .o files
that specify they are undefined and external to the .o file, yet document the
size of the variable. This allows the compiler to emit a single copy, but makes
it harder for our DWARF in .o files with the executable having a debug map
because the symbol for the global in the .o file doesn't exist in a section
that we can assign a fixed up linked address to, and also the DWARF contains
an invalid address in the "DW_OP_addr" location (always zero). This means that
the DWARF is incorrect and actually maps all such global varaibles to the
first file address in the .o file which is usually the first function. So we
can fix this in either of two ways: make a new fake section in the .o file
so that we have a file address in the .o file that we can relink, or fix the 
the variable as it is created in the .o file DWARF parser and actually give it
the file address from the executable. Each variable contains a 
SymbolContextScope, or a single pointer that helps us to recreate where the
variables came from (which module, file, function, etc). This context helps
us to resolve any file addresses that might be in the location description of
the variable by pointing us to which file the file address comes from, so we
can just replace the SymbolContextScope and also fix up the location, which we
would have had to do for the other case as well, and update the file address.
Now globals display correctly.

The above changes made it possible to determine if a variable is a global
or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag
for each variable (local, global, or static), yet DWARF provides no way for
us to classify these variables into these categories. We can now detect when
a variable has a simple address expressions as its location and this will help
us classify these correctly.

While making the above changes I also noticed that we had two symbol types:
eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same
thing: the symbol is not defined in the current object file. Symbol objects
also have a bit that specifies if a symbol is externally visible, so I got
rid of the eSymbolTypeExtern symbol type and moved all code locations that
used it to use the eSymbolTypeUndefined type.
 

llvm-svn: 144489

SimplifyAddress to handle either a 12-bit unsigned offset or the ARM +/-imm8
offsets (addressing mode 3).  This enables a load followed by an integer 
extend to be folded into a single load.

For example:
ldrb r1, [r0]       ldrb r1, [r0]
uxtb r2, r1     =>
mov  r3, r2         mov  r3, r1

llvm-svn: 144488

llvm-svn: 144487

This thing is looking a lot like a virtual register map now.

llvm-svn: 144486

Nobody cared, StackSlotColoring scans the instructions to find used stack
slots.

llvm-svn: 144485

Most of this stuff was supporting the old deferred spill code insertion
mechanism.  Modern spillers just edit machine code in place.

llvm-svn: 144484

literals of array type, materialise a temporary.

llvm-svn: 144483

The information was only used by the register allocator in
StackSlotColoring.

llvm-svn: 144482

It was off by default.

The new register allocators don't have the problems that made it
necessary to reallocate registers during stack slot coloring.

llvm-svn: 144481

And there was much rejoicing.

llvm-svn: 144480

The very complicated VirtRegRewriter is going away.

llvm-svn: 144479

This is dead code, all register allocators use InlineSpiller.

llvm-svn: 144478

The current register allocators all use the inline spiller.

llvm-svn: 144477

It is worth noting that the old spiller would split live ranges around
basic blocks. The new spiller doesn't do that.

PBQP should do its own live range splitting with
SplitEditor::splitSingleBlock() if desired.  See
RAGreedy::tryBlockSplit().

llvm-svn: 144476

RegAllocGreedy has been the default for six months now.

Deleting RegAllocLinearScan makes it possible to also delete
VirtRegRewriter and clean up the spiller code.

llvm-svn: 144475

Counting the number of occurences of each opcode is not a useful test.

llvm-svn: 144474

Or maybe we are just getting lucky.

llvm-svn: 144473

llvm-svn: 144472

Filed PR11364 to track the problem.  Should the register allocator
eliminate dead code?

llvm-svn: 144471

This test was committed with a bugfix to RemoveCopyByCommutingDef, but
that optimization is no longer triggered by this test.

llvm-svn: 144470

This test is for a very specific LocalRewriter bug.  LocalRewriter is
going away.

llvm-svn: 144469

or MemberExpr which refers to it. As a side-effect, MemberExprs which refer to
static member functions and static data members are now emitted as constant
expressions.

llvm-svn: 144468

llvm-svn: 144467

and remove them.

llvm-svn: 144466

[PCH] When completing an objc forward reference, do not serialize the chain of its categories because
it is going to be rewritten (and the chain will be serialized again), otherwise we may form a cycle in its
categories list when deserializing.

Also introduce ASTMutationListener::CompletedObjCForwardRef to notify that a forward reference
was completed; using Decl's isChangedSinceDeserialization/setChangedSinceDeserialization
is bug inducing and kinda gross, we should phase it out.

Fixes infinite loop in rdar://10418538.

llvm-svn: 144465

llvm-svn: 144464

I don't think this test does what is was supposed to do, and
LocalRewriter is going away anyway.

llvm-svn: 144463

llvm-svn: 144462

llvm-svn: 144461

llvm-svn: 144460

This test doesn't expose the issue with RAGreedy.

I filed PR11363 to track the missing InlineSpiller feature.

llvm-svn: 144459

The test is checking that the output doesn't contains any 'mov '
strings. It does contain movl, though.

llvm-svn: 144458

Add more AVX2 shift lowering support. Move AVX2 variable shift to use patterns instead of custom lowering code.

llvm-svn: 144457

llvm-svn: 144455