llvm-svn: 167981

llvm-svn: 167980

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

pointer, otherwise we will double free it when ExpressionEvaluationContextRecord
gets copied.

Fixes crash in rdar://12645424 & http://llvm.org/PR14252

llvm-svn: 167946

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

which is not coincidentally the only place it works, either (because
of how it tests for EH_TYPE symbols).

llvm-svn: 167935

llvm-svn: 167934

llvm-svn: 167933

llvm-svn: 167932

variables captured in a block. // rdar://12184410

llvm-svn: 167931

llvm-svn: 167930

llvm-svn: 167929

llvm-svn: 167928

llvm-svn: 167926

Patch by Jonathan Schleifer.

llvm-svn: 167925

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