[PM] Don't require analysis results to be const in the new pass manager.

I think this was just over-eagerness on my part. The analysis results
need to often be non-const because they need to (in some cases at least)
be updated by the transformation pass in order to remain correct. It
also makes lazy analyses (a common case) needlessly annoying to write in
order to make their entire state mutable.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200881 91177308-0d34-0410-b5e6-96231b3b80d8
[RegAlloc] Add a last chance recoloring mechanism when everything else failed to
find a register.

The idea is to choose a color for the variable that cannot be allocated and
recolor its interferences around. Unlike the current register allocation scheme,
it is allowed to change the color of an already assigned (but maybe not
splittable or spillable) live interval while propagating this change to its
neighbors.
In other word, there are two things that may help finding an available color:
- Already assigned variables (RS_Done) can be recolored to different color.
- The recoloring allows to catch solutions that needs to touch more that just
  the neighbors of the current allocated variable.

E.g.,
vA can use {R1, R2    }
vB can use {    R2, R3}
vC can use {R1        }
Where vA, vB, and vC cannot be split anymore (they are reloads for instance) and
they all interfere.

vA is assigned R1
vB is assigned R2
vC tries to evict vA but vA is already done.
=> Regular register allocation heuristic fails.

Last chance recoloring kicks in:
vC does as if vA was evicted => vC uses R1.
vC is marked as fixed.
vA needs to find a color.
None are available.
vA cannot evict vC: vC is a fixed virtual register now.
vA does as if vB was evicted => vA uses R2.
vB needs to find a color.
R3 is available.
Recoloring => vC = R1, vA = R2, vB = R3.

<rdar://problem/15947839>


git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200883 91177308-0d34-0410-b5e6-96231b3b80d8
Fix layering StringRef copy using BumpPtrAllocator.

Now to copy a string into a BumpPtrAllocator and get a StringRef to the copy:

   StringRef myCopy = myStr.copy(myAllocator);
   



git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200885 91177308-0d34-0410-b5e6-96231b3b80d8
Inliner uses a smaller inline threshold for callees with cold attribute.

Added command line option inlinecold-threshold to set threshold for inlining
functions with cold attribute. Listen to the cold attribute when it would
decrease the inline threshold.


git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200886 91177308-0d34-0410-b5e6-96231b3b80d8
Add address space argument to allowsUnalignedMemoryAccess.

On R600, some address spaces have more strict alignment
requirements than others.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200887 91177308-0d34-0410-b5e6-96231b3b80d8
Pass address space to allowsUnalignedMemoryAccesses

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200888 91177308-0d34-0410-b5e6-96231b3b80d8
Just returning false is the default.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200890 91177308-0d34-0410-b5e6-96231b3b80d8
Disable most IR-level transform passes on functions marked 'optnone'.
Ideally only those transform passes that run at -O0 remain enabled,
in reality we get as close as we reasonably can.
Passes are responsible for disabling themselves, it's not the job of
the pass manager to do it for them.


git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200892 91177308-0d34-0410-b5e6-96231b3b80d8
doesSectionRequireSymbols is meaningless on ELF, remove.

This is a nop. doesSectionRequireSymbols is only used from
isSymbolLinkerVisible. isSymbolLinkerVisible only use from ELF was in

if (!Asm.isSymbolLinkerVisible(Symbol) && !Symbol.isUndefined())
  return false;

if (Symbol.isTemporary())
  return false;

If the symbol is a temporary this code returns false and it is irrelevant if
we take the first if or not. If the symbol is not a temporary,
Asm.isSymbolLinkerVisible returns true without ever calling
doesSectionRequireSymbols.

This was an horrible leftover from when support for ELF was first added.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200894 91177308-0d34-0410-b5e6-96231b3b80d8
don't set HasReliableSymbolDifference for ELF.

It is only used in MachObjectWriter.cpp. Another leftover from early days
of ELF in MC.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200895 91177308-0d34-0410-b5e6-96231b3b80d8
Update the X86 assembler for .intel_syntax to accept
the << and >> bitwise operators.

rdar://15975725


git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200896 91177308-0d34-0410-b5e6-96231b3b80d8
Set default of inlinecold-threshold to 225.

225 is the default value of inline-threshold. This change will make sure
we have the same inlining behavior as prior to r200886.

As Chandler points out, even though we don't have code in our testing
suite that uses cold attribute, there are larger applications that do
use cold attribute.

r200886 + this commit intend to keep the same behavior as prior to r200886.
We can later on tune the inlinecold-threshold.

The main purpose of r200886 is to help performance of instrumentation based
PGO before we actually hook up inliner with analysis passes such as BPI and BFI.
For instrumentation based PGO, we try to increase inlining of hot functions and
reduce inlining of cold functions by setting inlinecold-threshold.

Another option suggested by Chandler is to use a boolean flag that controls
if we should use OptSizeThreshold for cold functions. The default value
of the boolean flag should not change the current behavior. But it gives us
less freedom in controlling inlining of cold functions.


git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200898 91177308-0d34-0410-b5e6-96231b3b80d8
[DAG] Don't pull the binary operation though the shift if the operands have opaque constants.

During DAGCombine visitShiftByConstant assumes that certain binary operations
with only constant operands can always be folded successfully. This is no longer
true when the constant is opaque. This commit fixes visitShiftByConstant by not
performing the optimization for opaque constants. Otherwise we would end up in
an infinite DAGCombine loop.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200900 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Wire up the analysis managers in the opt driver. This isn't really
necessary until we add analyses to the driver, but I have such an
analysis ready and wanted to split this out. This is actually exercised
by the existing tests of the new pass manager as the analysis managers
are cross-checked and validated by the function and module managers.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200901 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Back out one hunk of the patch in r200901 that was *supposed* to go
in my next patch. Sorry for the breakage.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200902 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Add a new "lazy" call graph analysis pass for the new pass manager.

The primary motivation for this pass is to separate the call graph
analysis used by the new pass manager's CGSCC pass management from the
existing call graph analysis pass. That analysis pass is (somewhat
unfortunately) over-constrained by the existing CallGraphSCCPassManager
requirements. Those requirements make it *really* hard to cleanly layer
the needed functionality for the new pass manager on top of the existing
analysis.

However, there are also a bunch of things that the pass manager would
specifically benefit from doing differently from the existing call graph
analysis, and this new implementation tries to address several of them:

- Be lazy about scanning function definitions. The existing pass eagerly
  scans the entire module to build the initial graph. This new pass is
  significantly more lazy, and I plan to push this even further to
  maximize locality during CGSCC walks.
- Don't use a single synthetic node to partition functions with an
  indirect call from functions whose address is taken. This node creates
  a huge choke-point which would preclude good parallelization across
  the fanout of the SCC graph when we got to the point of looking at
  such changes to LLVM.
- Use a memory dense and lightweight representation of the call graph
  rather than value handles and tracking call instructions. This will
  require explicit update calls instead of some updates working
  transparently, but should end up being significantly more efficient.
  The explicit update calls ended up being needed in many cases for the
  existing call graph so we don't really lose anything.
- Doesn't explicitly model SCCs and thus doesn't provide an "identity"
  for an SCC which is stable across updates. This is essential for the
  new pass manager to work correctly.
- Only form the graph necessary for traversing all of the functions in
  an SCC friendly order. This is a much simpler graph structure and
  should be more memory dense. It does limit the ways in which it is
  appropriate to use this analysis. I wish I had a better name than
  "call graph". I've commented extensively this aspect.

This is still very much a WIP, in fact it is really just the initial
bits. But it is about the fourth version of the initial bits that I've
implemented with each of the others running into really frustrating
problms. This looks like it will actually work and I'd like to split the
actual complexity across commits for the sake of my reviewers. =] The
rest of the implementation along with lots of wiring will follow
somewhat more rapidly now that there is a good path forward.

Naturally, this doesn't impact any of the existing optimizer. This code
is specific to the new pass manager.

A bunch of thanks are deserved for the various folks that have helped
with the design of this, especially Nick Lewycky who actually sat with
me to go through the fundamentals of the final version here.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200903 91177308-0d34-0410-b5e6-96231b3b80d8
[PM] Fix horrible typos that somehow didn't cause a failure in a C++11
build but spectacularly changed behavior of the C++98 build. =]

This shows my one problem with not having unittests -- basic API
expectations aren't well exercised by the integration tests because they
*happen* to not come up, even though they might later. I'll probably add
a basic unittest to complement the integration testing later, but
I wanted to revive the bots.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200905 91177308-0d34-0410-b5e6-96231b3b80d8
Delete all of the CodeGenInstructions from CodeGenTarget destructor.

git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200906 91177308-0d34-0410-b5e6-96231b3b80d8
A memcpy out of an fresh alloca is a no-op, delete it. Patch by Patrick Walton!


git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200907 91177308-0d34-0410-b5e6-96231b3b80d8
This small change reduces compile time for small programs on targets that have
large register files. The omission of Queries.clear() is perfectly safe because
LiveIntervalUnion::Query doesn't contain any data that needs freeing and
because LiveRegMatrix::runOnFunction happens to reset the OwningArrayPtr
holding Queries every time it is run, so there's no need to zero out the
queries either. Not having to do this for very large numbers of physregs
is a noticeable constant cost reduction in compilation of small programs.



git-svn-id: http://llvm.org/svn/llvm-project/llvm/trunk@200913 91177308-0d34-0410-b5e6-96231b3b80d8