For sanity, create a root when NumDataSuccs >= 4. Splitting large
subtrees will no longer be detrimental after my next checkin to handle
nested tree. A magic number of 4 is fine because single subtrees
seldom rejoin more than this. It makes subtrees easier to visualize
and heuristics more sane.

llvm-svn: 173399

Patch by Stefan Hepp.

llvm-svn: 173395

llvm-svn: 173382

Added comment to ObjCARC elaborating what is meant by the term 'Provenance' in 'Provenance Analysis'.

llvm-svn: 173374

No functionality change intended.

This captures the first two cases GPR32/64. For the others, we need
an addition operator (if we have one, I've not yet found it).

Based on a suggestion made by Tom Stellard in the AArch64 review!

llvm-svn: 173366

Original commit message:
Plug TTI into the speculation logic, giving it a real cost interface
that can be specialized by targets.

The goal here is not to be more aggressive, but to just be more accurate
with very obvious cases. There are instructions which are known to be
truly free and which were not being modeled as such in this code -- see
the regression test which is distilled from an inner loop of zlib.

Everywhere the TTI cost model is insufficiently conservative I've added
explicit checks with FIXME comments to go add proper modelling of these
cost factors.

If this causes regressions, the likely solution is to make TTI even more
conservative in its cost estimates, but test cases will help here.

llvm-svn: 173357

We use constant folding to see if an intrinsic evaluates to the same value as a
constant that we know. If we don't take the undefinedness into account we get a
value that doesn't match the actual implementation, and miscompiled code.

This was uncovered by Chandler's simplifycfg changes.

llvm-svn: 173356

of stage2 in a bootstrap. Still investigating....

llvm-svn: 173343

that can be specialized by targets.

The goal here is not to be more aggressive, but to just be more accurate
with very obvious cases. There are instructions which are known to be
truly free and which were not being modeled as such in this code -- see
the regression test which is distilled from an inner loop of zlib.

Everywhere the TTI cost model is insufficiently conservative I've added
explicit checks with FIXME comments to go add proper modelling of these
cost factors.

If this causes regressions, the likely solution is to make TTI even more
conservative in its cost estimates, but test cases will help here.

llvm-svn: 173342

unfolded constant expressions rather than checking each one
independently.

llvm-svn: 173341

a cost fuction that seems both a bit ad-hoc and also poorly suited to
evaluating constant expressions.

Notably, it is missing any support for trivial expressions such as
'inttoptr'. I could fix this routine, but it isn't clear to me all of
the constraints its other users are operating under.

The core protection that seems relevant here is avoiding the formation
of a select instruction wich a further chain of select operations in
a constant expression operand. Just explicitly encode that constraint.

Also, update the comments and organization here to make it clear where
this needs to go -- this should be driven off of real cost measurements
which take into account the number of constants expressions and the
depth of the constant expression tree.

llvm-svn: 173340

terms of cost rather than hoisting a single instruction.

This does *not* change the cost model! We still set the cost threshold
at 1 here, it's just that we track it by accumulating cost rather than
by storing an instruction.

The primary advantage is that we no longer leave no-op intrinsics in the
basic block. For example, this will now move both debug info intrinsics
and a single instruction, instead of only moving the instruction and
leaving a basic block with nothing bug debug info intrinsics in it, and
those intrinsics now no longer ordered correctly with the hoisted value.

Instead, we now splice the entire conditional basic block's instruction
sequence.

This also places the code for checking the safety of hoisting next to
the code computing the cost.

Currently, the only observable side-effect of this change is that debug
info intrinsics are no longer abandoned. I'm not sure how to craft
a test case for this, and my real goal was the refactoring, but I'll
talk to Dave or Eric about how to add a test case for this.

llvm-svn: 173339

llvm-svn: 173338

Previously, the code would scan the PHI nodes and build up a small
setvector of candidate value pairs in phi nodes to go and rewrite. Once
certain the rewrite could be performed, the code walks the set, and for
each one re-scans the entire PHI node list looking for nodes to rewrite
operands.

Instead, scan the PHI nodes once to check for hazards, and then scan it
a second time to rewrite the operands to selects. No set vector, and
a max of two scans.

The only downside is that we might form identical selects, but
instcombine or anything else should fold those easily, and it seems
unlikely to happen often.

llvm-svn: 173337

llvm-svn: 173335

structure being analyzed. No functionality changed.

llvm-svn: 173334

tests. No need to pay the high cost when we're never going to do
anything.

No functionality changed.

llvm-svn: 173331

pretty in doxygen, adding some of the details actually present in
a classic example where this matters (a loop from gzip and many other
compression algorithms), and a cautionary note about the risks inherent
in the transform. This has come up on the mailing lists recently, and
I suspect folks reading this code could benefit from going and looking
at the MI pass that can really deal with these issues.

llvm-svn: 173329

FIXME: Could they, unreachable(s), be removed?
FIXME: I could prefer the coding standards...
llvm-svn: 173325

...and fix a typo, s/#ifdef/#ifndef/

llvm-svn: 173324

llvm-svn: 173323

llvm-svn: 173322

Allow Mips16 routines to call Mips32 routines that have abi requirements
that either arguments or return values are passed in floating point 
registers. This handles only the pic case. We have not done non pic
for Mips16 yet in any form.

The libm functions are Mips32, so with this addition we have a complete
Mips16 hard float implementation.

We still are not able to complete mix Mip16 and Mips32 with hard float.
That will be the next phase which will have several steps. For Mips32
to freely call Mips16 some stub functions must be created.

llvm-svn: 173320

llvm-svn: 173318

Allow schedulers to order DAG edges by critical path. This makes
DFS-based heuristics more stable and effective.

llvm-svn: 173317

llvm-svn: 173313

llvm-svn: 173311

This is a helper class for the AttributeSetImpl class. It holds a set of
attributes that apply to a single element: function, return type, or
parameter.

These are uniqued.

llvm-svn: 173310

Push down the conversion of the alignment from the bit mask to a real number into the attribute implementation class.

llvm-svn: 173304

llvm-svn: 173302

This intrinsic is translated to ALLOC_EXPORT_WORD1_SWIZ, hence its
name. It is used to store vs/fs outputs

Patch by: Vincent Lejeune

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 173297

Patch by: Vincent Lejeune

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 173296

llvm-svn: 173293

This fixes some edge cases that we would get wrong with uint64_ts.
PR14986.

llvm-svn: 173289

llvm-svn: 173288

This causes crashes during the build of compiler-rt during selfhost. Add a
testcase for coverage.

llvm-svn: 173279

This does the right thing unless the multiplication overflows, but the old code
didn't handle that case either.

llvm-svn: 173276

llvm-svn: 173275

Clean up assignment of CalleeSaveStackSlotSize: get rid of the default and explicitly set this in every target that needs to change it from the default.

llvm-svn: 173270

This is still an egregious hack since we don't have a nice interface for this
kind of thing but should help the valgrind leak check buildbot to become green.

llvm-svn: 173267