of the bootstrap miscompare issue.

llvm-svn: 123299

the source of the bootstrap problem.

llvm-svn: 123298

llvm-svn: 123149

back to life.

llvm-svn: 123146

llvm-svn: 123144

without informing memdep.  This could cause nondeterminstic weirdness 
based on where instructions happen to get allocated, and will hopefully
breath some life into some broken testers.

llvm-svn: 123124

updating memdep when fusing stores together.  This fixes the crash optimizing
the bullet benchmark.

llvm-svn: 123091

llvm-svn: 123090

larger memsets.  Among other things, this fixes rdar://8760394 and
allows us to handle "Example 2" from http://blog.regehr.org/archives/320,
compiling it into a single 4096-byte memset:

_mad_synth_mute:                        ## @mad_synth_mute
## BB#0:                                ## %entry
	pushq	%rax
	movl	$4096, %esi             ## imm = 0x1000
	callq	___bzero
	popq	%rax
	ret

llvm-svn: 123089

P and P+1 are relative to the same base pointer.

llvm-svn: 123087

memset into a single larger memset.

llvm-svn: 123086

Split memset formation logic out into its own
"tryMergingIntoMemset" helper function.

llvm-svn: 123081

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