Add doInitialization and doFinalization methods to ModulePass's, to allow them to be re-initialized and reused on multiple Module's.

Patch by Pedro Artigas.

llvm-svn: 168008

llvm-svn: 168006

llvm-svn: 168001

PPC64 target.  The five tests modified herein test code generation that is
sensitive to the code model selected.  So I've added -code-model=small to
the RUN commands for each.

Since small code model is the default, this has no effect for now; but this
prepares us for eventually changing the default to medium code model for PPC64.

Test changes verified with small and medium code model as default on
powerpc64-unknown-linux-gnu.  All tests continue to pass.

llvm-svn: 167999

llvm-svn: 167998

Some small related fixups to TestingGuide too.

llvm-svn: 167996

llvm-svn: 167991

llvm-svn: 167989

llvm-svn: 167988

llvm-svn: 167987

llvm-svn: 167986

Approved by Chris Lattner.

llvm-svn: 167984

llvm-svn: 167979

FileCheck.

llvm-svn: 167978

llvm-svn: 167976

llvm-svn: 167975

llvm-svn: 167974

llvm-svn: 167973

llvm-svn: 167972

llvm-svn: 167971

llvm-svn: 167970

llvm-svn: 167969

llvm-svn: 167968

The stack realignment code was fixed to work when there is stack realignment and
a dynamic alloca is present so this shouldn't cause correctness issues anymore.

Note that this also enables generation of AVX instructions for memset
under the assumptions:
- Unaligned loads/stores are always fast on CPUs supporting AVX
- AVX is not slower than SSE
We may need some tweaked heuristics if one of those assumptions turns out not to
be true.

Effectively reverts r58317. Part of PR2962.

llvm-svn: 167967

For now, this uses 8 on-stack elements. I'll need to do some profiling
to see if this is the best number.

Pointed out by Jakob in post-commit review.

llvm-svn: 167966

llvm-svn: 167965

font.  These were formatted in bold, but that's not correct.

llvm-svn: 167964

The code pattern "imm0_255_neg" is used for checking if an immediate value is a small negative number.
This patch changes the definition of negative from -0..-255 to -1..-255. I am changing this because of
a bug that we had in some of the patterns that assumed that "subs" of zero does not set the carry flag.

rdar://12028498

llvm-svn: 167963

llvm-svn: 167962

llvm-svn: 167961

Loads from i1 become loads from i8 followed by trunc
Stores to i1 become zext to i8 followed by store to i8

Fixes PR13291

llvm-svn: 167948

llvm-svn: 167947

eh table and handler data if there are no landing pads in the function.
Patch by Logan Chien with some cleanups from me.

llvm-svn: 167945

llvm-svn: 167943

Iterating over the children of each node in the potential vectorization
plan must happen in a deterministic order (because it affects which children
are erased when two children conflict). There was no need for this data
structure to be a map in the first place, so replacing it with a vector
is a small change.

I believe that this was the last remaining instance if iterating over the
elements of a Dense* container where the iteration order could matter.
There are some remaining iterations over std::*map containers where the order
might matter, but so long as the Value* for instructions in a block increase
with the order of the instructions in the block (or decrease) monotonically,
then this will appear to be deterministic.

llvm-svn: 167942

llvm-svn: 167940

When an instruction as written requires 32-bit mode and we're assembling
in 64-bit mode, or vice-versa, issue a more specific diagnostic about
what's wrong.

rdar://12700702

llvm-svn: 167937

llvm-svn: 167936

llvm-svn: 167933

llvm-svn: 167928