Sort relocation entries before they are written out to a file. MIPS ABI
imposes a constraint that GOT16 referring to a local symbol or HI16 has to be
followed immediately by a matching LO16 relocation.

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

Emit all directives except for ".cprestore" during asm printing rather than emit
them as machine instructions. Directives ".set noat" and ".set at" are now
emitted only at the beginning and end of a function except in the case where
they are emitted to enclose .cpload with an immediate operand that doesn't fit
in 16-bit field or unaligned load/stores.

Also, make the following changes:
- Remove function isUnalignedLoadStore and use a switch-case statement to
  determine whether an instruction is an unaligned load or store.

- Define helper function CreateMCInst which generates an instance of an MCInst
  from an opcode and a list of operands.

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

Mark flag neverHasSideEffects of pattern-less instructions that do not have
any side effects.

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

MSVC doesn't like the mixing of declarations and statements in a .c file.

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

Add a note about a cute little fabs optimization.

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

Add two missed instcombines related to compares with nsw arithmetic.

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

Try to use the CWD if the path to the GCDA output is not available (e.g., the
executable has been moved to another machine). If that's not available
(read-only or something), then exit gracefully.
<rdar://problem/11111686>

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

Remove trailing white space.

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

Use a SmallVector and linear lookup instead of a DenseSet - SourceMap values
will always be tiny sets, so DenseSet is overkill (SmallSet won't work as we
need iteration support).

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

Add member EmitNOAT and its setter and getter functions to class MipsFunctionInfo.
If EmitNOAT is true, directives ".set noat" and ".set at" are emitted at the
beginning and end of a function.

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

Add a test for the previous commit. Also, remove two tests that were
testing a) the wrong behavior or b) something that I'm already testing
in the new test.

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

Use DW_AT_low_pc for a single entry point into a routine.

Fixes PR10105

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

Reapply r153423; the original commit was fine.  The failing test, distray, had
undefined behavior, which Rafael was kind enough to fix.

Original commit message for r153423:
Use the new range metadata in computeMaskedBits and add a new optimization to
instruction simplify that lets us remove an and when loding a boolean value.

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

ARMLoadStoreOptimizer invalidates register liveness.

This pass tries to update kill flags, but there are still many bugs.
Passes after the load/store optimizer don't need accurate liveness, so
don't even try.

<rdar://problem/11101911>

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

Print SSA and liveness tracking flags in MF::print().

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

Branch folding may invalidate liveness.

Branch folding can use a register scavenger to update liveness
information when required. Don't do that if liveness information is
already invalid.

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

Invalidate liveness in Thumb2ITBlockPass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153516 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

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

llvm/docs/*.html: Fix markups.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153508 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

Prune some includes

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153502 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

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

Fix bug in LowerConstantPool.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153498 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

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

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

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

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

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

Reserve hardware registers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153486 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

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

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 '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

Add InitializeNativeTargetDisassembler function.

Patch by Ojab.

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

Unit test for PR11950: LSR crash.

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

Use the file in the inlined die rather than the compile unit for
backtrace locations.

Testcase forthcoming, but I wanted to get some testing here.

Should fix:

PR12323
PR12314
rdar://11091100

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

153465 was incorrect. In this code we wanted to check that the pointer operand is of pointer type (and not vector type).

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

Made RuntimeDyldMachO support vanilla i386
relocations.  The algorithm is the same as
that for x86_64.  Scattered relocations, a
feature present in i386 but not on x86_64,
are not yet supported.

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

PR12357: The pointer was used before it was checked.

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

LSR ivchain bug fix: corner case with ConstantExpr.

Fixes PR11950.

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

comment typo

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

eliminate an unneeded branch, part of PR12357

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

fix a failure path to print the right thing, part of PR12357

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

Tidy.

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

Tidy.

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

Revert r153423 as this is causing failures on our internal nightly testers.

Original commit message:
Use the new range metadata in computeMaskedBits and add a new optimization to
instruction simplify that lets us remove an and when loading a boolean value.

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

LSR cleanup: potential bug caught by PVS-Studio.

Thanks Andrey.

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

docs/lit: Add some notes on the lit test run output format.

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

[tsan] treat vtable pointer updates in a special way (requires tbaa); fix a bug (forgot to return true after instrumenting); make sure the tsan tests are run

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

No need to do an expensive stable sort for a bunch of integers.

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

Add missing include of <new>

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

Fix GetMainExecutable on kFreeBSD.
Patch by Sylvestre Ledru!

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

Remove stale CBackend tests.

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

TableGen: Don't emit the llvm intrinsic -> gcc builtin table, its only user was the c backend.

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

Prune some includes and forward declarations.

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

Add a debug statement.

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

Add some fixes to the configure script  for isInf and add
--enable-libcpp to projects/sample.

Patch by Dmitri Shubin with additional fixes by me.

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

Update documentation for old api changes.

Fixes PR12050

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

Use the new range metadata in computeMaskedBits and add a new optimization to
instruction simplify that lets us remove an and when loding a boolean value.

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

Prune includes and replace uses of ARMRegisterInfo.h with ARMBaeRegisterInfo.h

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

Replace uses of ARMBaseInstrInfo and ARMTargetMachine with the Base versions.

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

Teach instsimplify how to simplify comparisons of pointers which are
constant-offsets of a common base using the generic GEP-walking logic
I added for computing pointer differences in the same situation.

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

Switch the pointer-difference simplification logic to only work with
inbounds GEPs. This isn't really necessary for simplifying pointer
differences, but I'm planning to re-use the same code to simplify
pointer comparisons where it is necessary. Since real code almost
exclusively uses inbounds GEPs, it doesn't seem worth it to support the
extra complexity of turning it on and off. If anyone would like that
back, feel free to shout. Note that instcombine will still catch any of
these patterns.

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

Prune some includes and forward declarations.

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

Prune some includes and forward declarations.

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

This file is no longer needed (DejaGNU-isms removed from code)

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

s/restrict/describe/
Thanks Duncan.

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

Teach the function cloner (and thus the inliner) to simplify PHINodes
aggressively. There are lots of dire warnings about this being expensive
that seem to predate switching to the TrackingVH-based value remapper
that is automatically updated on RAUW. This makes it easy to not just
prune single-entry PHIs, but to fully simplify PHIs, and to recursively
simplify the newly inlined code to propagate PHINode simplifications.

This introduces a bit of a thorny problem though. We may end up
simplifying a branch condition to a constant when we fold PHINodes, and
we would like to nuke any dead blocks resulting from this so that time
isn't wasted continually analyzing them, but this isn't easy. Deleting
basic blocks *after* they are fully cloned and mapped into the new
function currently requires manually updating the value map. The last
piece of the simplification-during-inlining puzzle will require either
switching to WeakVH mappings or some other piece of refactoring. I've
left a FIXME in the testcase about this.

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

Fix lit failure on cmake-clang-x64_64-linux bot, apparently due to its having
a very (*very*) old version of Python (2.4?)

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

Continue cleanup of LIT, getting rid of the remaining artifacts from dejagnu

* Removed test/lib/llvm.exp - it is no longer needed
* Deleted the dg.exp reading code from test/lit.cfg. There are no dg.exp files
  left in the test suite so this code is no longer required. test/lit.cfg is
  now much shorter and clearer
* Removed a lot of duplicate code in lit.local.cfg files that need access to
  the root configuration, by adding a "root" attribute to the TestingConfig
  object. This attribute is dynamically computed to provide the same
  information as was previously provided by the custom getRoot functions.
* Documented the config.root attribute in docs/CommandGuide/lit.pod

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

Move the instruction simplification of callsite arguments in the inliner
to instead rely on much more generic and powerful instruction
simplification in the function cloner (and thus inliner).

This teaches the pruning function cloner to use instsimplify rather than
just the constant folder to fold values during cloning. This can
simplify a large number of things that constant folding alone cannot
begin to touch. For example, it will realize that 'or' and 'and'
instructions with certain constant operands actually become constants
regardless of what their other operand is. It also can thread back
through the caller to perform simplifications that are only possible by
looking up a few levels. In particular, GEPs and pointer testing tend to
fold much more heavily with this change.

This should (in some cases) have a positive impact on compile times with
optimizations on because the inliner itself will simply avoid cloning
a great deal of code. It already attempted to prune proven-dead code,
but now it will be use the stronger simplifications to prove more code
dead.

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

Add an asserting ValueHandle to the block simplification code which will
fire if anything ever invalidates the assumption of a terminator
instruction being unchanged throughout the routine.

I've convinced myself that the current definition of simplification
precludes such a transformation, so I think getting some asserts
coverage that we don't violate this agreement is sufficient to make this
code safe for the foreseeable future.

Comments to the contrary or other suggestions are of course welcome. =]
The bots are now happy with this code though, so it appears the bug here
has indeed been fixed.

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

Use the isReachableFromEntry method.

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

Don't form a WeakVH around the sentinel node in the instructions BB
list. This is a bad idea. ;] I'm hopeful this is the bug that's showing
up with the MSVC bots, but we'll see.

It is definitely unnecessary. InstSimplify won't do anything to
a terminator instruction, we don't need to even include it in the
iteration range. We can also skip the now dead terminator check,
although I've made it an assert to help document that this is an
important invariant.

I'm still a bit queasy about this because there is an implicit
assumption that the terminator instruction cannot be RAUW'ed by the
simplification code. While that appears to be true at the moment, I see
no guarantee that would ensure it remains true in the future. I'm
looking at the cleanest way to solve that...

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

Avoid using dominatedBySlowTreeWalk.

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

Try to harden the recursive simplification still further. This is again
spotted by inspection, and I've crafted no test case that triggers it on
my machine, but some of the windows builders are hitting what looks like
memory corruption, so *something* is amiss here.

This patch takes a more generalized approach to eliminating
double-visits. Imagine code such as:

  %x = ...
  %y = add %x, 1
  %z = add %x, %y

You can imagine that if we simplify %x, we would add %y and %z to the
list. If the use-chain order happens to cause us to add them in reverse
order, we could pull %y off first, and simplify it, adding %z to the
list. We now have %z on the list twice, and will reference it after it
is deleted.

Currently, all my test cases happen to not trigger this, likely due to
the use-chain ordering, but there seems no guarantee that such
a situation could not occur, so we should handle it correctly.

Again, if anyone knows how to craft a testcase that actually triggers
this, please let me know.

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

Don't add the instruction about to be RAUW'ed and erased to the
worklist. This can happen in theory when an instruction uses itself,
such as a PHI node. This was spotted by inspection, and unfortunately
I've not been able to come up with a test case that would trigger it. If
anyone has ideas, let me know...

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

Fix null to integer conversion warnings.

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

FileCheck-ize this test. Note the FIXME I've introduced here: we've
regressed seriously here, we are no longer removing allocas during
inline cleanup. This appears to be because of lifetime markers "using"
them. =/ I'll look into this shortly.

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

Refactor the interface to recursively simplifying instructions to be tad
bit simpler by handling a common case explicitly.

Also, refactor the implementation to use a worklist based walk of the
recursive users, rather than trying to use value handles to detect and
recover from RAUWs during the recursive descent. This fixes a very
subtle bug in the previous implementation where degenerate control flow
structures could cause mutually recursive instructions (PHI nodes) to
collapse in just such a way that From became equal to To after some
amount of recursion. At that point, we hit the inf-loop that the assert
at the top attempted to guard against. This problem is defined away when
not using value handles in this manner. There are lots of comments
claiming that the WeakVH will protect against just this sort of error,
but they're not accurate about the actual implementation of WeakVHs,
which do still track RAUWs.

I don't have any test case for the bug this fixes because it requires
running the recursive simplification on unreachable phi nodes. I've no
way to either run this or easily write an input that triggers it. It was
found when using instruction simplification inside the inliner when
running over the nightly test-suite.

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

Remove always true variable.

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

Add a small release not about the range metadata.

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

Fix small-integer VAARG on SVR4 ABI PPC64.

The PPC64 SVR4 ABI requires integer stack arguments, and thus the var. args., that
are smaller than 64 bits be zero extended to 64 bits.

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

Add the ability to promote legal integer VAARGs. This is required for the PPC64 SVR4 ABI.

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

Fix the MSVC build.

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

PTX: Fix predicate logic bug

Code such as:

%vreg100 = setcc %vreg10, -1, SETNE
brcond %vreg10, %tgt

was being incorrectly morphed into

%vreg100 = and %vreg10, 1
brcond %vreg10, %tgt

where the 'and' instruction could be eliminated since
such logic is on 1-bit types in the PTX back-end, leaving
us with just:

brcond %vreg10, %tgt

which essentially gives us inverted branch conditions.

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

More IndVarSimplify cleanup.

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

First part of PR12251. Add documentation and verifier support for the range
metadata.

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

add EP_OptimizerLast extension point

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

It's possible for two types, which are isomorphic, to be added to the
destination module, but one of them isn't used in the destination module. If
another module comes along and the uses the unused type, there could be type
conflicts when the modules are finally linked together. (This happened when
building LLVM.)

The test that was reduced is:

Module A:

%Z = type { %A }
%A = type { %B.1, [7 x x86_fp80] }
%B.1 = type { %C }
%C = type { i8* }

declare void @func_x(%C*, i64, i64)
declare void @func_z(%Z* nocapture)

Module B:

%B = type { %C.1 }
%C.1 = type { i8* }
%A.2 = type { %B.3, [5 x x86_fp80] }
%B.3 = type { %C.1 }

define void @func_z() {
  %x = alloca %A.2, align 16
  %y = getelementptr inbounds %A.2* %x, i64 0, i32 0, i32 0
  call void @func_x(%C.1* %y, i64 37, i64 927) nounwind
  ret void
}

declare void @func_x(%C.1*, i64, i64)
declare void @func_y(%B* nocapture)

(Unfortunately, this test doesn't fail under llvm-link, only during an LTO
linking.) The '%C' and '%C.1' clash. The destination module gets the '%C'
declaration. When merging Module B, it looks at the '%C.1' subtype of the '%B'
structure. It adds that in, because that's cool. And when '%B.3' is processed,
it uses the '%C.1'. But the '%B' has used '%C' and we prefer to use '%C'. So the
'@func_x' type is changed to 'void (%C*, i64, i64)', but the type of '%x' in
'@func_z' remains '%A.2'. The GEP resolves to a '%C.1', which conflicts with the
'@func_x' signature.

We can resolve this situation by making sure that the type is used in the
destination before saying that it should be used in the module being merged in.

With this fix, LLVM and Clang both compile under LTO.
<rdar://problem/10913281>

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

ARM tidy up ARMConstantIsland.cpp.

No functional change, just tidy up the code and nomenclature a bit.

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

Pretty-printing comments for literal floating point in .s files.

Dump the hex representation to the comment stream as well as the float
value.

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

Add a hook in MCELFObjectTargetWriter to allow targets to sort relocation
entries in the relocation table before they are written out to the file.

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

Don't convert objc_retainAutoreleasedReturnValue to objc_retain if it
is retaining the return value of an invoke that it immediately follows.

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

It's not possible to insert code immediately after an invoke in the
same basic block, and it's not safe to insert code in the successor
blocks if the edges are critical edges. Splitting those edges is
possible, but undesirable, especially on the unwind side. Instead,
make the bottom-up code motion to consider invokes to be part of
their successor blocks, rather than part of their parent blocks, so
that it doesn't push code past them and onto the edges. This fixes
PR12307.

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

Make it feasible for clients using EngineBuilder to capture the TargetMachine that is created as part of selecting the appropriate target.
This is necessary if the client wants to be able to mutate TargetOptions (for example, fast FP math mode) after the initial creation of the ExecutionEngine.

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

Add support for register masks to PBQP.

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