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

This allows Polly to vectorize more code. Fix the relevant test cases.

llvm-svn: 167923

llvm-svn: 167922

llvm-svn: 167921

non-trivial if they would not call a move operation, even if they would in fact
call a trivial copy operation. A proper fix is to follow, but this small
directed fix is intended for porting to the 3.2 release branch.

llvm-svn: 167920

and we resolve it to a specific function based on the type which it's used as,
don't forget to mark it as referenced.

Fixes a regression introduced in r167514.

llvm-svn: 167918

llvm-svn: 167917

llvm-svn: 167916

llvm-svn: 167915

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

Found by Richard Smith in post-commit review of r167906.

llvm-svn: 167911

Thread::ResetFrameZeroRegisters() clear the UnwindLLDB object when
resetting the thread's register state.

llvm-svn: 167910

* getMostSpecialized()

/// \param Index if non-NULL and the result of this function is non-nULL,
/// receives the index corresponding to the resulting function template
/// specialization.

* DeduceTemplateArguments()

/// \param Name the name of the function being called. This is only significant
/// when the function template is a conversion function template, in which
/// case this routine will also perform template argument deduction based on
/// the function to which

llvm-svn: 167909

llvm-svn: 167908