This should fix the PPC buildbots.

llvm-svn: 178558

Updated tests and docs.

llvm-svn: 178556

llvm-svn: 178554

The new instruction scheduling models provide information about the
number of cycles consumed on each processor resource. This makes it
possible to estimate ILP more accurately than simply counting
instructions / issue width.

The functions getResourceDepth() and getResourceLength() now identify
the limiting processor resource, and return a cycle count based on that.

This gives more precise resource information, particularly in traces
that use one resource a lot more than others.

llvm-svn: 178553

llvm-svn: 178552

The IHM_ prefix was a fairly gross abbreviation to try to hit three
characters for uniqueness.

llvm-svn: 178551

llvm-svn: 178550

llvm-svn: 178549

Summary:
This makes it possible to share code between lib/AST/MicrosoftCXXABI.cpp
and lib/CodeGen/MicrosoftCXXABI.cpp.  No functionality change.

Also adds comments about the layout of the member pointer structs as I
currently understand them.

Reviewers: rjmccall

CC: timurrrr, cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D590

llvm-svn: 178548

This is helps on architectures where i8,i16 are not legal but we have byte, and
short loads/stores. Allowing us to merge copies like the one below on ARM.

copy(char *a, char *b, int n) {
 do {
   int t0 = a[0];
   int t1 = a[1];
   b[0] = t0;
   b[1] = t1;

radar://13536387

llvm-svn: 178546

llvm-svn: 178545

llvm-svn: 178544

case when [[clang::fallthrough]]; is used in a method of a local class.

llvm-svn: 178543

Basically we have always special-cased the top-level statement of an
unwrapped line (the one with ParenLevel == 0) and that lead to several
inconsistencies. All added tests were formatted in a strange way, for
example:

Before:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa();
if (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
        .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
            .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
                .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa()) {
}

After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa();
if (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
        .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
        .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
        .aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa()) {
}

llvm-svn: 178542

call memory indirect (32 and 64 bit).

llvm-svn: 178541

Fixes PR15642.

llvm-svn: 178540

llvm-svn: 178539

llvm-svn: 178538

Summary: Store comments in ScopedLineState

Reviewers: klimek, djasper

Reviewed By: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D609

llvm-svn: 178537

llvm-svn: 178536

WTFAnnotateBenignRaceSized and AnnotateBenignRaceSized.

llvm-svn: 178534

The iterator could be invalidated when it's recursively deleting a whole bunch
of constant expressions in a constant initializer.

Note: This was only reproducible if `opt' was run on a `.bc' file. If `opt' was
run on a `.ll' file, it wouldn't crash. This is why the test first pushes the
`.ll' file through `llvm-as' before feeding it to `opt'.

PR15440

llvm-svn: 178531

Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 178530

llvm-svn: 178529

There is only a few new instructions, the rest is handled with patterns.

llvm-svn: 178528

SPARC v9 extends all ALU instructions to 64 bits, so we simply need to
add patterns to use them for both i32 and i64 values.

llvm-svn: 178527

The last resort pattern produces 6 instructions, and there are still
opportunities for materializing some immediates in fewer instructions.

llvm-svn: 178526

SPARC v9 defines new 64-bit shift instructions. The 32-bit shift right
instructions are still usable as zero and sign extensions.

This adds new F3_Sr and F3_Si instruction formats that probably should
be used for the 32-bit shifts as well. They don't really encode an
simm13 field.

llvm-svn: 178525

The 'sparc' architecture produces 32-bit code while 'sparcv9' produces
64-bit code.

It is also possible to run 32-bit code using SPARC v9 instructions with:

  llc -march=sparc -mattr=+v9

llvm-svn: 178524

This is far from complete, but it is enough to make it possible to write
test cases using i64 arguments.

Missing features:
- Floating point arguments.
- Receiving arguments on the stack.
- Calls.

llvm-svn: 178523

We are going to use the same registers for 32-bit and 64-bit values, but
in two different register classes. The I64Regs register class has a
larger spill size and alignment.

The addition of an i64 register class confuses TableGen's type
inference, so it is necessary to clarify the type of some immediates and
the G0 register.

In 64-bit mode, pointers are i64 and should use the I64Regs register
class. Implement getPointerRegClass() to dynamically provide the pointer
register class depending on the subtarget. Use ptr_rc and iPTR for
memory operands.

Finally, add the i64 type to the IntRegs register class. This register
class is not used to hold i64 values, I64Regs is for that. The type is
required to appease TableGen's type checking in output patterns like this:

  def : Pat<(add i64:$a, i64:$b), (ADDrr $a, $b)>;

SPARC v9 uses the same ADDrr instruction for i32 and i64 additions, and
TableGen doesn't know to check the type of register sub-classes.

llvm-svn: 178522

Thanks to Bill Schmidt for finding this in review of r178480.

llvm-svn: 178521

variable in a C99 inline (but not static-inline or extern-inline)
function definition.

The standard doesn't actually say that this doesn't apply to
"extern inline" definitions, but that seems like a useful extension,
and it at least doesn't have the obvious flaw that a static
mutable variable in an externally-available definition does.

rdar://13535367

llvm-svn: 178520

Buffered means a later divide may be executed out-of-order while a
prior divide is sitting (buffered) in a reservation station.

You can tell it's not pipelined, because operations that use it
reserve it for more than one cycle:

def : WriteRes<WriteIDiv, [HWPort0, HWDivider]> {
  let Latency = 25;
  let ResourceCycles = [1, 10];
}

We don't currently distinguish between an unpipeline operation and one
that is split into multiple micro-ops requiring the same unit. Except
that the later may have NumMicroOps > 1 if they also consume
issue/dispatch resources.

llvm-svn: 178519

Refactor invalidateRegions to take SVals instead of Regions as input and teach RegionStore
about processing LazyCompoundVal as a top-level “escaping” value.

This addresses several false positives that get triggered by the NewDelete checker, but the
underlying issue is reproducible with other checkers as well (for example, MallocChecker).

llvm-svn: 178518

Make sure we do not generate line info for debugging-related frame setup.
Follow-up to r178361 / rdar://problem/12767564

llvm-svn: 178517

This is a heuristic to make up for the fact that the analyzer doesn't
model C++ containers very well. One example is modeling that
'std::distance(I, E) == 0' implies 'I == E'. In the future, it would be
nice to model this explicitly, but for now it just results in a lot of
false positives.

The actual heuristic checks if the base type has a member named 'begin' or
'iterator'. If so, we treat the constructors and destructors of that type
as opaque, rather than inlining them.

This is intended to drastically reduce the number of false positives
reported with experimental destructor support turned on. We can tweak the
heuristic in the future, but we'd rather err on the side of false negatives
for now.

<rdar://problem/13497258>

llvm-svn: 178516

Certain properties of a function can determine ahead of time whether or not
the function is inlineable, such as its kind, its signature, or its
location. We can cache this value in the FunctionSummaries map to avoid
rechecking these static properties for every call.

Note that the analyzer may still decide not to inline a specific call to
a function because of the particular dynamic properties of the call along
the current path.

No intended functionality change.

llvm-svn: 178515

The summaries lasted for the lifetime of the map anyway; no reason to
include an extra allocation.

Also, use SmallBitVector instead of BitVector to track the visited basic
blocks -- most functions will have less than 64 basic blocks -- and
use bitfields for the other fields to reduce the size of the structure.

No functionality change.

llvm-svn: 178514

This is controlled by the 'suppress-c++-stdlib' analyzer-config flag.
It is currently off by default.

This is more suppression than we'd like to do, since obviously there can
be user-caused issues within 'std', but it gives us the option to wield
a large hammer to suppress false positives the user likely can't work
around.

llvm-svn: 178513