Add InitializeNativeTargetDisassembler function.

Patch by Ojab.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153476 91177308-0d34-0410-b5e6-96231b3b80d8
Add 'undef's to make SWIG happier. Patch by Baozeng Ding.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153479 91177308-0d34-0410-b5e6-96231b3b80d8
SCEV fix: Handle loop invariant loads.

Fixes PR11882: NULL dereference in ComputeLoadConstantCompareExitLimit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153480 91177308-0d34-0410-b5e6-96231b3b80d8
Add a debug option to dump PBQP graphs during register allocation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153483 91177308-0d34-0410-b5e6-96231b3b80d8
ARM has a peephole optimization which looks for a def / use pair. The def
produces a 32-bit immediate which is consumed by the use. It tries to 
fold the immediate by breaking it into two parts and fold them into the
immmediate fields of two uses. e.g
       movw    r2, #40885
       movt    r3, #46540
       add     r0, r0, r3
=>
       add.w   r0, r0, #3019898880
       add.w   r0, r0, #30146560
;
However, this transformation is incorrect if the user produces a flag. e.g.
       movw    r2, #40885
       movt    r3, #46540
       adds    r0, r0, r3
=>
       add.w   r0, r0, #3019898880
       adds.w  r0, r0, #30146560
Note the adds.w may not set the carry flag even if the original sequence
would.

rdar://11116189


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153484 91177308-0d34-0410-b5e6-96231b3b80d8
Reserve hardware registers.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153486 91177308-0d34-0410-b5e6-96231b3b80d8
During MachineCopyPropagation a register may be the source operand of multiple
copies being considered for removal. Make sure to track all of the copies,
rather than just the most recent encountered, by holding a DenseSet instead of
an unsigned in SrcMap.

No test case - couldn't reduce something with a sane size.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153487 91177308-0d34-0410-b5e6-96231b3b80d8
Rewrite computation of Value in adjustFixupValue so that the upper 48-bits are
cleared. No functionality change.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153491 91177308-0d34-0410-b5e6-96231b3b80d8
Post-ra LICM should take care not to hoist an instruction that would clobber a
register that's read by the preheader terminator.

rdar://11095580


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153492 91177308-0d34-0410-b5e6-96231b3b80d8
Define function MipsGetSymAndOffset which returns a fixup's symbol and the
offset applied to it.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153493 91177308-0d34-0410-b5e6-96231b3b80d8
Retrieve and add the offset of a symbol in applyFixup rather than retrieve and
set it in MipsMCCodeEmitter::getMachineOpValue. Assert in getMachineOpValue if
MachineOperand MO is of an unexpected type. 



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153494 91177308-0d34-0410-b5e6-96231b3b80d8
Add T9 to the list of live-in registers of the entry basic block. 



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153497 91177308-0d34-0410-b5e6-96231b3b80d8
Fix bug in LowerConstantPool. 



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153498 91177308-0d34-0410-b5e6-96231b3b80d8
Pass the llvm IR pointer value and offset to the constructor of
MachinePointerInfo when getStore is called to create a node that stores an
argument passed in register to the stack. Without this change, the post RA 
scheduler will fail to discover the dependencies between the stores
instructions and the instructions that load from a structure passed by value. 

The link to the related discussion is here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048055.html


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153499 91177308-0d34-0410-b5e6-96231b3b80d8
Remove unnecessary llvm:: qualifications

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153500 91177308-0d34-0410-b5e6-96231b3b80d8
Prune some includes

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153502 91177308-0d34-0410-b5e6-96231b3b80d8
Make a seemingly tiny change to the inliner and fix the generated code
size bloat. Unfortunately, I expect this to disable the majority of the
benefit from r152737. I'm hopeful at least that it will fix PR12345. To
explain this requires... quite a bit of backstory I'm afraid.

TL;DR: The change in r152737 actually did The Wrong Thing for
linkonce-odr functions. This change makes it do the right thing. The
benefits we saw were simple luck, not any actual strategy. Benchmark
numbers after a mini-blog-post so that I've written down my thoughts on
why all of this works and doesn't work...

To understand what's going on here, you have to understand how the
"bottom-up" inliner actually works. There are two fundamental modes to
the inliner:

1) Standard fixed-cost bottom-up inlining. This is the mode we usually
   think about. It walks from the bottom of the CFG up to the top,
   looking at callsites, taking information about the callsite and the
   called function and computing th expected cost of inlining into that
   callsite. If the cost is under a fixed threshold, it inlines. It's
   a touch more complicated than that due to all the bonuses, weights,
   etc. Inlining the last callsite to an internal function gets higher
   weighth, etc. But essentially, this is the mode of operation.

2) Deferred bottom-up inlining (a term I just made up). This is the
   interesting mode for this patch an r152737. Initially, this works
   just like mode #1, but once we have the cost of inlining into the
   callsite, we don't just compare it with a fixed threshold. First, we
   check something else. Let's give some names to the entities at this
   point, or we'll end up hopelessly confused. We're considering
   inlining a function 'A' into its callsite within a function 'B'. We
   want to check whether 'B' has any callers, and whether it might be
   inlined into those callers. If so, we also check whether inlining 'A'
   into 'B' would block any of the opportunities for inlining 'B' into
   its callers. We take the sum of the costs of inlining 'B' into its
   callers where that inlining would be blocked by inlining 'A' into
   'B', and if that cost is less than the cost of inlining 'A' into 'B',
   then we skip inlining 'A' into 'B'.

Now, in order for #2 to make sense, we have to have some confidence that
we will actually have the opportunity to inline 'B' into its callers
when cheaper, *and* that we'll be able to revisit the decision and
inline 'A' into 'B' if that ever becomes the correct tradeoff. This
often isn't true for external functions -- we can see very few of their
callers, and we won't be able to re-consider inlining 'A' into 'B' if
'B' is external when we finally see more callers of 'B'. There are two
cases where we believe this to be true for C/C++ code: functions local
to a translation unit, and functions with an inline definition in every
translation unit which uses them. These are represented as internal
linkage and linkonce-odr (resp.) in LLVM. I enabled this logic for
linkonce-odr in r152737.

Unfortunately, when I did that, I also introduced a subtle bug. There
was an implicit assumption that the last caller of the function within
the TU was the last caller of the function in the program. We want to
bonus the last caller of the function in the program by a huge amount
for inlining because inlining that callsite has very little cost.
Unfortunately, the last caller in the TU of a linkonce-odr function is
*not* the last caller in the program, and so we don't want to apply this
bonus. If we do, we can apply it to one callsite *per-TU*. Because of
the way deferred inlining works, when it sees this bonus applied to one
callsite in the TU for 'B', it decides that inlining 'B' is of the
*utmost* importance just so we can get that final bonus. It then
proceeds to essentially force deferred inlining regardless of the actual
cost tradeoff.

The result? PR12345: code bloat, code bloat, code bloat. Another result
is getting *damn* lucky on a few benchmarks, and the over-inlining
exposing critically important optimizations. I would very much like
a list of benchmarks that regress after this change goes in, with
bitcode before and after. This will help me greatly understand what
opportunities the current cost analysis is missing.

Initial benchmark numbers look very good. WebKit files that exhibited
the worst of PR12345 went from growing to shrinking compared to Clang
with r152737 reverted.

- Bootstrapped Clang is 3% smaller with this change.
- Bootstrapped Clang -O0 over a single-source-file of lib/Lex is 4%
  faster with this change.

Please let me know about any other performance impact you see. Thanks to
Nico for reporting and urging me to actually fix, Richard Smith, Duncan
Sands, Manuel Klimek, and Benjamin Kramer for talking through the issues
today.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153506 91177308-0d34-0410-b5e6-96231b3b80d8
llvm/docs/*.html: Fix markups.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153508 91177308-0d34-0410-b5e6-96231b3b80d8
Add an MRI::tracksLiveness() flag.

Late optimization passes like branch folding and tail duplication can
transform the machine code in a way that makes it expensive to keep the
register liveness information up to date. There is a fuzzy line between
register allocation and late scheduling where the liveness information
degrades.

The MRI::tracksLiveness() flag makes the line clear: While true,
liveness information is accurate, and can be used for register
scavenging. Once the flag is false, liveness information is not
accurate, and can only be used as a hint.

Late passes generally don't need the liveness information, but they will
sometimes use the register scavenger to help update it. The scavenger
enforces strict correctness, and we have to spend a lot of code to
update register liveness that may never be used.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153511 91177308-0d34-0410-b5e6-96231b3b80d8
fix what looks like a real logic bug, found by PVS-Studio (part of PR12357)


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