Differential Revision: http://reviews.llvm.org/D19490

llvm-svn: 267637

Differential Revision: http://reviews.llvm.org/D19562

llvm-svn: 267636

Differential Revision: http://reviews.llvm.org/D19518

llvm-svn: 267635

the prologue.

Do not use basic blocks that have EFLAGS live-in as prologue if we need
to realign the stack. Realigning the stack uses AND instruction and this
clobbers EFLAGS.

An other alternative would have been to save and restore EFLAGS around
the stack realignment code, but this is likely inefficient.

Fixes PR27531.

llvm-svn: 267634

llvm-svn: 267633

table for a module / PCH, never map from a normal declaration of a class to an
injected-class-name declaration (or vice versa). Those declarations live in
distinct lookup tables and should not be confused.

We really shouldn't be using a CXXRecordDecl to represent an
injected-class-name in the first place; I've filed PR27532 so we don't forget.

llvm-svn: 267632

llvm-svn: 267631

Thanks again to Richard Smith for pointing this out.

llvm-svn: 267630

Differential Revision: http://reviews.llvm.org/D19568

llvm-svn: 267629

Also move the explanatory comment with it.

llvm-svn: 267628

Previously we were recursing on our operands for unary and binary operators regardless of whether we knew how to reason about the operator in question.  This has the effect of doing a potentially large amount of work, only to throw it away.  By checking whether the operation is one LVI can handle, we can cut short the search and return the (overdefined) answer more quickly.  The quality of the results produced should not change.

llvm-svn: 267626

This is an addendum to r229921.

llvm-svn: 267625

llvm-svn: 267624

When the simple analysis provided by MachineBasicBlock::computeRegisterLiveness
fails, fall back on the LivePhysReg utility.

llvm-svn: 267623

Thanks to that information we wouldn't lie on a register being live whereas it
is not.

llvm-svn: 267622

Now, it is possible to know that partial definitions are dead definitions and
recognize that clobbered registers are also dead.

llvm-svn: 267621

As pointed out by John Regehr over in http://reviews.llvm.org/D19485, LVI was being incredibly stupid about applying its transfer rules.  Rather than gathering local facts from the expression itself, it was simply giving up entirely if one of the inputs was overdefined.  This greatly impacts the precision of the overall analysis and makes it far more fragile as well.

This patch builds on 267609 which did the same thing for unary casts.

llvm-svn: 267620

NVPTXLowerKernelArgs is required for correctness, so it should not be guarded
by CodeGenOpt::None.

NVPTXPeephole is optimization only, so it should be skipped when
CodeGenOpt::None.

llvm-svn: 267619

Essentially, I was using the wrong size function.  For types which were sized, but not primitive, I wasn't getting a useful size for the operand and failed an assert.  I fixed this, and also added a guard that the input is a sized type.  Test case is for the original mistake.  I'm not sure how to actually exercise the sized type check.

llvm-svn: 267618

I'll clean this up and add a test case shortly.  I want to make sure this does actually fix the bots; if not, I'll revert.

llvm-svn: 267617

Use __attribute__((regparm(x))) to ensure the compiler enregisters at least some arguments when calling functions.

Differential Revision: http://reviews.llvm.org/D19548

llvm-svn: 267616

We need the default ratio to be sufficiently large that it triggers transforms 
based on block frequency info (BFI) and plays well with the recently introduced
BranchProbability used by CGP.

Differential Revision: http://reviews.llvm.org/D19435

llvm-svn: 267615

llvm-svn: 267614

This lets Writer.cpp know that they are got relative, which will allow
further simplifications.

llvm-svn: 267613

llvm-svn: 267612

Follow-up to r267464. Thanks to Richard Smith for pointing this out!

llvm-svn: 267611

Summary:
On windows platform assert() call creates two distinct CFG edges
which are coverage-instrumented. Simply calling assert would
change coverage numbers on the platform.

Subscribers: kubabrecka

Differential Revision: http://reviews.llvm.org/D19514

llvm-svn: 267610

As pointed out by John Regehr over in http://reviews.llvm.org/D19485, LVI was being incredibly stupid about applying its transfer rules. Rather than gathering local facts from the expression itself, it was simply giving up entirely if one of the inputs was overdefined. This greatly impacts the precision of the overall analysis and makes it far more fragile as well.

This patch implements only the unary operation case. Once this is in, I'll implement the same for the binary operations.

Differential Revision: http://reviews.llvm.org/D19492

llvm-svn: 267609

Differential Revision: http://reviews.llvm.org/D19439

llvm-svn: 267608

Differential Revision: http://reviews.llvm.org/D17176

llvm-svn: 267606

The destination buffer that sprintf uses is restrict qualified, we do
not need to worry about derived pointers referenced via format
specifiers.

This reverts commit r267580.

llvm-svn: 267605

llvm-svn: 267604

Every caller was doing it.

llvm-svn: 267603

llvm-svn: 267602

r267556 made backslashes escape the next character
unconditionally in rsp files.  This test echos a path into
a rsp file, and paths contain backslashes on Windows. Since
it's not important for this test to get the filename from
the rsp file, just pass it regularly.

llvm-svn: 267601

When --reproduce <path> is given, then we need to concatenate input
file paths to the given path to save input files to the directory.
Previously, path concatenation didn't handle Windows drive letters
so it could generate invalid paths such as "C:\D:\foo". It also didn't
handle ".." path components, so it could produce some bad paths
such as "foo/../../etc/passwd".

In this patch, Windows drive letters and ".." are removed before
concatenating paths.

Differential Revision: http://reviews.llvm.org/D19551

llvm-svn: 267600

llvm-svn: 267599

llvm-svn: 267598

Fixed a bug in loop vectorization with conditional store.

Differential Revision: http://reviews.llvm.org/D19532

llvm-svn: 267597

llvm-svn: 267596