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

the related comma pasting extension.

In certain cases, we used to get two diagnostics for what is essentially one
extension.  This change suppresses the first diagnostic in certain cases
where we know we're going to print the second diagnostic.  The
diagnostic is redundant, and it can't be suppressed in the definition
of the macro because it points at the use of the macro, so we want to
avoid printing it if possible.

The implementation works by detecting constructs which look like comma
pasting at the time of the definition of the macro; this information
is then used when the macro is used.  (We can't actually detect
whether we're using the comma pasting extension until the macro is
actually used, but we can detecting constructs which will be comma
pasting if the varargs argument is elided.)

<rdar://problem/12292192>

llvm-svn: 167907