llvm-svn: 144150

When merging two uncollapsed DomainValues, place a link to the active
DomainValue from the passive DomainValue.  This allows old stale
references to the passive DomainValue to be updated to point to the
active DomainValue.

The new resolve() function finds the active DomainValue and updates the
pointer.

This change makes old live-out lists more useful since they may contain
uncollapsed DomainValues that have since been merged into other
DomainValues.

llvm-svn: 144149

llvm-svn: 144148

This allows clear() to be called on a DomainValue with references.

llvm-svn: 144147

llvm-svn: 144146

llvm-svn: 144145

opaque values.  Silly C type system.

llvm-svn: 144144

// rdar://10415026

llvm-svn: 144143

llvm-svn: 144142

Change the flow of the SATestAdd so that it could be used for regenerating
the reference output without exiting with an error.

llvm-svn: 144141

Patch by Jack Carter.

llvm-svn: 144139

*headdesk*

llvm-svn: 144138

llvm-svn: 144136

There is no need to involve the LiveRegs array and kill() any longer.

llvm-svn: 144133

No functional change.

llvm-svn: 144132

This new function will decrement the reference count, and collapse a
domain value when the last reference is gone.

This simplifies DomainValue reference counting, and decouples it from
the LiveRegs array.

llvm-svn: 144131

and is different than the normal name.

llvm-svn: 144130

basic blocks containing calls. This works around a problem in which
these artificial dependencies can get tied up in calling seqeunce
scheduling in a way that makes the graph unschedulable with the current
approach of using artificial physical register dependencies for calling
sequences. This fixes PR11314.

llvm-svn: 144124

llvm-svn: 144123

No functional change intended.

llvm-svn: 144122

llvm-svn: 144121

llvm-svn: 144120

type is strong by default too. // rdar://10410903

llvm-svn: 144118

The old value may still be referenced by some live-out list, and we
don't wan't to collapse those instructions twice.

This fixes the "Can only swizzle VMOVD" assertion in some armv7 SPEC
builds.

<rdar://problem/10413292>

llvm-svn: 144117

llvm-svn: 144116

llvm-svn: 144115

Analysis by Ted:
"
    if (stateZero && !stateNotZero) {

is checking to see if:

  (A)  "it is possible for the value to be zero"   (stateZero)

    AND

  (B) "it is not possible for the value to be non-zero"  (!stateNotZero)

That said, the only way for both B to be true AND A to be false is if the path is completely infeasible by the time we reach the divide-by-zero check.  For the most part (all cases?), such cases should automatically get pruned out at branches (i.e., an infeasible path gets dropped), which is the case in our tests.  So the question is whether or not such an infeasible path might not get dropped earlier?  I can't envision any right now.

Indeed, the rest of the checker assumes that if the bug condition didn't fire then 'stateNotZero' is non-NULL:

    C.addTransition(stateNotZero);
"

llvm-svn: 144114

llvm-svn: 144113

llvm-svn: 144112

llvm-svn: 144111

which they do. This avoids all of the default argument promotions that
we (1) don't want, and (2) undo during that custom type checking, and
makes sure that we don't run into trouble during template
instantiation. Fixes PR11320.

llvm-svn: 144110

llvm-svn: 144108

LICM pass now understands invariant load metadata.  Nothing generates this yet so it will currently never get used in real tests

llvm-svn: 144107

llvm-svn: 144105

llvm-svn: 144104

Add support for trimming constants to GetDemandedBits. This fixes some funky
constant generation that occurs when stores are expanded for targets that don't
support unaligned stores natively.

llvm-svn: 144102

When this field is true it means that the load is from constant (runt-time or compile-time) and so can be hoisted from loops or moved around other memory accesses

llvm-svn: 144100

llvm-svn: 144099

llvm-svn: 144095

llvm-svn: 144094