llvm-svn: 122572

llvm-svn: 122565

llvm-svn: 122561

Fix a thinko pointed out by Frits van Bommel: looking through global variables in isBytewiseValue is not safe.

llvm-svn: 122550

This allows us to compile "int cst[] = {-1, -1, -1};" into
  movl  $-1, 16(%rsp)
  movq  $-1, 8(%rsp)
instead of
  movl  _cst+8(%rip), %eax
  movl  %eax, 16(%rsp)
  movq  _cst(%rip), %rax
  movq  %rax, 8(%rsp)

llvm-svn: 122548

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

llvm-svn: 122458

llvm-svn: 121944

llvm-svn: 121362

substitution because it doesn't actually change the IR.  Patch by
Jakub Staszak!

llvm-svn: 121361

zextOrTrunc(), and APSInt methods extend(), extOrTrunc() and new method
trunc(), to be const and to return a new value instead of modifying the
object in place.

llvm-svn: 121120

20040709-1.c from the gcc testsuite.  I was using the size of a
pointer instead of the pointee.  This fixes rdar://8713376

llvm-svn: 120519

llvm-svn: 120347

llvm-svn: 119948

method in MemDep instead of inserting an instruction, doing a query,
then removing it.  Neither operation is effectively cached.

llvm-svn: 119930

allowing the memcpy to be eliminated.

Unfortunately, the requirements on byval's without explicit 
alignment are really weak and impossible to predict in the 
mid-level optimizer, so this doesn't kick in much with current
frontends.  The fix is to change clang to set alignment on all
byval arguments.

llvm-svn: 119916

llvm-svn: 119908

saying "it would be bad", give an example of what is going on.

llvm-svn: 119695

refusing to optimize two memcpy's like this:

copy A <- B
copy C <- A

if it couldn't prove that noalias(B,C).  We can eliminate
the copy by producing a memmove instead of memcpy.

llvm-svn: 119694

source and dest are known to not overlap.

llvm-svn: 119692

there is no need to check to see if the source and dest of a memcpy are noalias,
behavior is undefined if not.

llvm-svn: 119691

out of processMemCpy into its own function.

llvm-svn: 119687

uint64_t, plus fixes for places I missed before.

llvm-svn: 116875

llvm-svn: 116858

use uint64_t.

llvm-svn: 116839

Get rid of static constructors for pass registration.  Instead, every pass exposes an initializeMyPassFunction(), which
must be called in the pass's constructor.  This function uses static dependency declarations to recursively initialize
the pass's dependencies.

Clients that only create passes through the createFooPass() APIs will require no changes.  Clients that want to use the
CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
before parsing commandline arguments.

I have tested this with all standard configurations of clang and llvm-gcc on Darwin.  It is possible that there are problems
with the static dependencies that will only be visible with non-standard options.  If you encounter any crash in pass
registration/creation, please send the testcase to me directly.

llvm-svn: 116820

llvm-svn: 116815

forwarding is implemented with a load/store pair rather than a memcpy.

llvm-svn: 116637

perform initialization without static constructors AND without explicit initialization
by the client.  For the moment, passes are required to initialize both their
(potential) dependencies and any passes they preserve.  I hope to be able to relax
the latter requirement in the future.

llvm-svn: 116334

llvm-svn: 115996

memcpy alignment is the minimum of the incoming alignments.

Fixes PR 8266.

llvm-svn: 115305

of the source, not the original alignment since it may no longer
be valid.

Fixes rdar://8400094

llvm-svn: 114781

llvm-svn: 110460

llvm-svn: 110410

ID member as the sole unique type identifier.  Clean up APIs related to this change.

llvm-svn: 110396

llvm-svn: 109687

llvm-svn: 109510

llvm-svn: 109509

llvm-svn: 109502

llvm-svn: 109092

llvm-svn: 109045