llvm-svn: 168042

For global variables that get the same value stored into them
everywhere, GlobalOpt will replace them with a constant. The problem is
that a thread-local GlobalVariable looks like one value (the address of
the TLS var), but is different between threads.

This patch introduces Constant::isThreadDependent() which returns true
for thread-local variables and constants which depend on them (e.g. a GEP
into a thread-local array), and teaches GlobalOpt not to track such
values.

llvm-svn: 168037

The new OpenCL SPIR extension spec will define separate SPIR for 32 and 64 bit architectures.

llvm-svn: 168036

the utility for extracting a chain of operations from the IR, thought that it
might as well combine any constants it came across (rather than just returning
them along with everything else).  On the other hand, the factorization code
would like to see the individual constants (this is quite reasonable: it is
much easier to pull a factor of 3 out of 2*3 than it is to pull it out of 6;
you may think 6/3 isn't so hard, but due to overflow it's not as easy to undo
multiplications of constants as it may at first appear).  This patch therefore
makes LinearizeExprTree stupider: it now leaves optimizing to the optimization
part of reassociate, and sticks to just analysing the IR.

llvm-svn: 168035

llvm-svn: 168030

llvm-svn: 168029

Make a bunch of floating point operations on vectors Expand so that instruction selection won't fail.

llvm-svn: 168028

llvm-svn: 168025

Jakub Staszak spotted this in review. I don't notice these things
until I manually rerun benchmarks. But reducing unit tests is a very
high priority.

llvm-svn: 168021

llvm-svn: 168013

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

llvm-svn: 167991

Approved by Chris Lattner.

llvm-svn: 167984

llvm-svn: 167976

llvm-svn: 167974

llvm-svn: 167972

llvm-svn: 167970

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

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

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

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

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

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

llvm-svn: 167926

This seems like redundant leftovers from r142288 - exposing
TargetData::parseSpecifier to LLParser - which got reverted. Removes
redunant td != NULL checks in parseSpecifier, and simplifies the
interface to parseSpecifier and init.

llvm-svn: 167924

llvm-svn: 167922

llvm-svn: 167916

Set FFLOOR for vectors to expand on CellSPU to keep instruction selection from failing on llvm.floor of a vector.

llvm-svn: 167914

llvm-svn: 167913

llvm-svn: 167912

Do some cleanup of the code while here.

Inspired by patch by Logan Chien!

llvm-svn: 167904

llvm-svn: 167894

llvm-svn: 167893

llvm-svn: 167892