Move CallbackVHs dtor inline, it can be devirtualized in many cases. Move the other virtual methods out of line as they are only called from within Value.cpp anyway.

llvm-svn: 157123

StringMap. This was redundant and unnecessarily bloated the MDString class.

Because the MDString class is a "Value" and will never have a "name", and
because the Name field in the Value class is a pointer to a StringMap entry, we
repurpose the Name field for an MDString. It stores the StringMap entry in the
Name field, and uses the normal methods to get the string (name) back.

PR12474

llvm-svn: 154429

value pointer by making the value pointer into a pointer-int pair with 2 bits
available for flags.

llvm-svn: 154279

correlated pairs of pointer arguments at the callsite. This is designed
to recognize the common C++ idiom of begin/end pointer pairs when the
end pointer is a constant offset from the begin pointer. With the
C-based idiom of a pointer and size, the inline cost saw the constant
size calculation, and this provides the same level of information for
begin/end pairs.

In order to propagate this information we have to search for candidate
operations on a pair of pointer function arguments (or derived from
them) which would be simplified if the pointers had a known constant
offset. Then the callsite analysis looks for such pointer pairs in the
argument list, and applies the appropriate bonus.

This helps LLVM detect that half of bounds-checked STL algorithms
(such as hash_combine_range, and some hybrid sort implementations)
disappear when inlined with a constant size input. However, it's not
a complete fix due the inaccuracy of our cost metric for constants in
general. I'm looking into that next.

Benchmarks showed no significant code size change, and very minor
performance changes. However, specific code such as hashing is showing
significantly cleaner inlining decisions.

llvm-svn: 152752

a common collection of methods on Value, and share their implementation.
We had two variations in two different places already, and I need the
third variation for inline cost estimation.

Reviewed by Duncan Sands on IRC, but further comments here welcome.

llvm-svn: 152490

returns false in the event the computation feeding into the pointer is
unreachable, which maybe ought to be true -- but this is at least consistent
with undef->isDereferenceablePointer().) Fixes PR11825!

llvm-svn: 148671

- Calling getUser in a loop is much more expensive than iterating over a few instructions.
- Use it instead of the open-coded loop in AddrModeMatcher.
- 5% speedup on ARMDisassembler.cpp Release builds.

llvm-svn: 145810

Remove Value::getNameStr. It has been deprecated for a while and provides no additional value over getName().

llvm-svn: 144657

llvm-svn: 144648

llvm-svn: 135375

which was just replaceAllUsesWith without some assertions.  It was
needed back when type refinement was alive.

llvm-svn: 135253

patch brings numerous advantages to LLVM.  One way to look at it
is through diffstat:
 109 files changed, 3005 insertions(+), 5906 deletions(-)

Removing almost 3K lines of code is a good thing.  Other advantages
include:

1. Value::getType() is a simple load that can be CSE'd, not a mutating
   union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
   uniques them.  This means that the compiler doesn't merge them structurally
   which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
   struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
   in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead 
   "const Type *" everywhere.

Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.  
"LLVM 3.0" is the right time to do this.

There are still some cleanups pending after this, this patch is large enough
as-is.

llvm-svn: 134829

-Wshorten-64-to-32 warning in Instructions.h.

llvm-svn: 133708

"Reinstate r133435 and r133449 (reverted in r133499) now that the clang
self-hosted build failure has been fixed (r133512)."

Due to some additional warnings.

llvm-svn: 133700

self-hosted build failure has been fixed (r133512).

llvm-svn: 133513

llvm-svn: 133499

Change PHINodes to store simple pointers to their incoming basic blocks,
instead of full-blown Uses.

Note that this loses an optimization in SplitCriticalEdge(), because we
can no longer walk the use list of a BasicBlock to find phi nodes. See
the comment I removed starting "However, the foreach loop is slow for
blocks with lots of predecessors".

Extend replaceAllUsesWith() on a BasicBlock to also update any phi
nodes in the block's successors. This mimics what would have happened
when PHINodes were proper Users of their incoming blocks. (Note that
this only works if OldBB->replaceAllUsesWith(NewBB) is called when
OldBB still has a terminator instruction, so it still has some
successors.)

llvm-svn: 133435

dereferencable, noticed by inspection.

llvm-svn: 124085

User.cpp.

llvm-svn: 123575

new gcc warning that complains on self-assignments and
self-initializations.

llvm-svn: 122458

Revert r122114 (CallbackVH observing use-list changes) because it caused severe slowdowns on the Linux self-host configuration.

llvm-svn: 122279

llvm-svn: 122114

function so that it can live in Analysis instead of
VMCore.

llvm-svn: 121885

llvm-svn: 118846

testing for dereferenceable pointers into a helper function,
isDereferenceablePointer.  Teach it how to reason about GEPs
with simple non-zero indices.

Also eliminate ArgumentPromtion's IsAlwaysValidPointer,
which didn't check for weak externals or out of range gep
indices.

llvm-svn: 118840

are still on the list.  This might happen if a CallbackVH created some new value
handles for the old value when doing RAUW.  Barf if it occurs, since it is almost
certainly a mistake.

llvm-svn: 109495

hanging off a value, then the dropping code will intentionally not drop
it too (since this is almost certainly a bug).

llvm-svn: 109337

for creating and populating NamedMDNodes.

llvm-svn: 109061

code in unreachable blocks, which have have use-def cycles.
This fixes PR7514.

llvm-svn: 107071

llvm-svn: 99564

methods to try to have the type predicates be more logically positioned.

llvm-svn: 96349

and T->isPointerTy().  Convert most instances of the first form to the second form.
Requested by Chris.

llvm-svn: 96344

parameter with a default value, instead of just hardcoding it in the
implementation.  The limit of MaxLookup = 6 was introduced in r69151 to fix
a performance problem with O(n^2) behavior in instcombine, but the scalarrepl
pass is relying on getUnderlyingObject to go all the way back to an AllocaInst.
Making the limit part of the method signature makes it clear that by default
the result is limited and should help avoid similar problems in the future.
This fixes pr6126.

llvm-svn: 94433

twine can be represented as a single StringRef. Use the new methode to simplify
some twine users.

llvm-svn: 93317

Avoid going through the LLVMContext for type equality where it's safe to dereference the type pointer.

llvm-svn: 92726

llvm-svn: 92663

why one was replaced with the other.  Even in the specific case of 
debug information, it doesn't make sense to transfer the location over,
this will just result in jumbled loc info.

llvm-svn: 92241

I asked Devang to do back on Sep 27.  Instead of going through the
MetadataContext class with methods like getMD() and getMDs(), just
ask the instruction directly for its metadata with getMetadata()
and getAllMetadata().

This includes a variety of other fixes and improvements: previously
all Value*'s were bloated because the HasMetadata bit was thrown into
value, adding a 9th bit to a byte.  Now this is properly sunk down to
the Instruction class (the only place where it makes sense) and it
will be folded away somewhere soon.

This also fixes some confusion in getMDs and its clients about 
whether the returned list is indexed by the MDID or densely packed.
This is now returned sorted and densely packed and the comments make
this clear.

This introduces a number of fixme's which I'll follow up on.

llvm-svn: 92235

can be banging on a context at a time, this isn't needed.  Owen, please
review.

llvm-svn: 85728

llvm-svn: 84336