llvm-svn: 120298

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: 116800

llvm-svn: 115996

llvm-svn: 113914

(The Ada bindings probably need it too, but all the
obvious places to change say "do not edit this file".)

llvm-svn: 113618

being actively maintained, improved, or extended.

llvm-svn: 112356

that many of these things, so the memory savings isn't significant,
and there are now situations where there can be alignments greater
than 128.

llvm-svn: 110836

llvm-svn: 110460

llvm-svn: 110410

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

llvm-svn: 110396

to avoid undefined behavior on overflow, noticed by John Regehr.

llvm-svn: 109594

llvm-svn: 109045

alignment to match what's used in clang and GCC for __alignof, rather
than trying to guess what Legalize is going to be doing.

llvm-svn: 102206

even if the element of the array has no size.

llvm-svn: 101662

llvm-svn: 100709

in particular, they end up aligning strings at 16-byte boundaries, and
there's no way for GlobalOpt to check OptForSize.

llvm-svn: 100172

This fixes test/Transforms/GlobalOpt/gv-align.ll.

llvm-svn: 100161

handling constant unions.

llvm-svn: 98680

llvm-svn: 98662

llvm-svn: 98656

terms of store and load, which means bitcasting between scalar
integer and vector has endian-specific results, which undermines
this whole approach.

llvm-svn: 97137

the number of value bits, not the number of bits of allocation for in-memory
storage.

Make getTypeStoreSize and getTypeAllocSize work consistently for arrays and
vectors.

Fix several places in CodeGen which compute offsets into in-memory vectors
to use TargetData information.

This fixes PR1784.

llvm-svn: 97064

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

llvm-svn: 96344

when we don't have one laying around.  Useful if you don't
have an llvmcontext handy.

llvm-svn: 94468

llvm-svn: 91612

llvm-svn: 90656

- Privatize a typedef.
- Call the InvalidateEntry when refining a type.

llvm-svn: 90655

llvm-svn: 90640

llvm-svn: 90639

llvm-svn: 90588

llvm-svn: 90383

function, converting "dyn_cast" to "cast", asserting the correct things, and
other general cleanups.

llvm-svn: 90371

llvm-svn: 90366

Patch by Howard Hinnant!

llvm-svn: 90365

that it doesn't have dangling pointers when abstract types are resolved. This
modifies it somewhat to address comments: making the "StructLayoutMap" an
anonymous structure, calling "removeAbstractTypeUser" when appropriate, and
adding asserts where helpful.

llvm-svn: 90362

This is probably not confined to *just* these two things.

Anyway, the llvm-gcc front-end may look up the structure layout information for
an abstract type. That information will be stored into a table with the FE's
TD. Instruction combine can come along and also ask for information on that
abstract type, but for a separate TD (the one associated with the pass manager).

After the type is refined, the old structure layout information in the pass
manager's TD file is out of date. If a new type is allocated in the same space
as the old-unrefined type, then the structure type information in the pass
manager's TD file will be wrong, but won't know it.

Fix this by making the TD's structure type information an abstract type user.

llvm-svn: 89176

this gives llvm-gcc generated modules the right data.

llvm-svn: 86435

datatypes on a given CPU.  This is intended to allow instcombine and other
transformations to avoid converting big sequences of operations to an
inconvenient width, and will help clean up after SRoA.  See also "Adding 
legal integer sizes to TargetData" on Feb 1, 2009 on llvmdev, and PR3451.

Comments welcome.

llvm-svn: 86370

llvm-svn: 86369