This adds a new set-like type which represents a set of preserved
analysis passes. The set is managed via the opaque PassT::ID() void*s.
The expected convenience templates for interacting with specific passes
are provided. It also supports a symbolic "all" state which is
represented by an invalid pointer in the set. This state is nicely
saturating as it comes up often. Finally, it supports intersection which
is used when finding the set of preserved passes after N different
transforms.

The pass API is then changed to return the preserved set rather than
a bool. This is much more self-documenting than the previous system.
Returning "none" is a conservatively correct solution just like
returning "true" from todays passes and not marking any passes as
preserved. Passes can also be dynamically preserved or not throughout
the run of the pass, and whatever gets returned is the binding state.
Finally, preserving "all" the passes is allowed for no-op transforms
that simply can't harm such things.

Finally, the analysis managers are changed to instead of blindly
invalidating all of the analyses, invalidate those which were not
preserved. This should rig up all of the basic preservation
functionality. This also correctly combines the preservation moving up
from one IR-layer to the another and the preservation aggregation across
N pass runs. Still to go is incrementally correct invalidation and
preservation across IR layers incrementally during N pass runs. That
will wait until we have a device for even exposing analyses across IR
layers.

While the core of this change is obvious, I'm not happy with the current
testing, so will improve it to cover at least some of the invalidation
that I can test easily in a subsequent commit.

llvm-svn: 195241

Before:
  void f() {
    CHECK_EQ(aaaa, (
                       *bbbbbbbbb)->cccccc)
        << "qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq";
  }

After:
  void f() {
    CHECK_EQ(aaaa, (*bbbbbbbbb)->cccccc)
        << "qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq";
  }

llvm-svn: 195240

Somehow, this ADT got missed which is moderately terrifying considering
the efficiency of move for it.

The code to implement move semantics for it is pretty horrible
currently but was written to reasonably closely match the rest of the
code. Unittests that cover both copying and moving (at a basic level)
added.

llvm-svn: 195239

llvm-svn: 195238

llvm-svn: 195237

llvm-svn: 195236

llvm-svn: 195235

llvm-svn: 195230

llvm-svn: 195229

llvm-svn: 195216

The -triple option is used to create a named tarball of the release binaries.

Also disable the RPATH modifications on Mac OS X. It's not needed.

llvm-svn: 195193

The FunctionPassManager is now itself a function pass. When run over
a function, it runs all N of its passes over that function. This is the
1:N mapping in the pass dimension only. This allows it to be used in
either a ModulePassManager or potentially some other manager that
works on IR units which are supersets of Functions.

This commit also adds the obvious adaptor to map from a module pass to
a function pass, running the function pass across every function in the
module.

The test has been updated to use this new pattern.

llvm-svn: 195192

Instead of permanently outputting "MVLL" as the file checksum, clang
will create gcno and gcda checksums by hashing the destination block
numbers of every arc. This allows for llvm-cov to check if the two gcov
files are synchronized.

Regenerated the test files so they contain the checksum. Also added
negative test to ensure error when the checksums don't match.

llvm-svn: 195191

Takes file checksum as an argument to write to .gcda file.

llvm-svn: 195190

a module-specific interface. This is the first of many steps necessary
to generalize the infrastructure such that we can support both
a Module-to-Function and Module-to-SCC-to-Function pass manager
nestings.

After a *lot* of attempts that never worked and didn't even make it to
a committable state, it became clear that I had gotten the layering
design of analyses flat out wrong. Four days later, I think I have most
of the plan for how to correct this, and I'm starting to reshape the
code into it. This is just a baby step I'm afraid, but starts separating
the fundamentally distinct concepts of function analysis passes and
module analysis passes so that in subsequent steps we can effectively
layer them, and have a consistent design for the eventual SCC layer.

As part of this, I've started some interface changes to make passes more
regular. The module pass accepts the module in the run method, and some
of the constructor parameters are gone. I'm still working out exactly
where constructor parameters vs. method parameters will be used, so
I expect this to fluctuate a bit.

This actually makes the invalidation less "correct" at this phase,
because now function passes don't invalidate module analysis passes, but
that was actually somewhat of a misfeature. It will return in a better
factored form which can scale to other units of IR. The documentation
has gotten less verbose and helpful.

llvm-svn: 195189

Removing a custom error diagnostic and replacing it with a stock one. Added a test case to ensure the diagnostic was firing properly.

llvm-svn: 195188

llvm-svn: 195187

llvm-svn: 195186

Masking operations (where only some number of the low bits are being kept) are
selected to rldicl(x, 0, mb). If x is a logical right shift (which would become
rldicl(y, 64-n, n)), we might be able to fold the two instructions together:

  rldicl(rldicl(x, 64-n, n), 0, mb) -> rldicl(x, 64-n, mb) for n <= mb

The right shift is really a left rotate followed by a mask, and if the explicit
mask is a more-restrictive sub-mask of the mask implied by the shift, only one
rldicl is needed.

llvm-svn: 195185

llvm-svn: 195184

and not polymorphically deleted and they are the only thing that derive
from DIE.

llvm-svn: 195183

and LexicalScopes, we're not using it.

llvm-svn: 195182

llvm-svn: 195181

llvm-svn: 195180

llvm-svn: 195179

to or from 'id' and qualified-id types.
// rdar://15454846

llvm-svn: 195178

natural stop id is updated.
<rdar://problem/15496603> 

llvm-svn: 195177

llvm-svn: 195176

llvm-svn: 195175

[analyzer] Fix an infinite recursion in region invalidation by adding block count to the BlockDataRegion.

llvm-svn: 195174

llvm-svn: 195173

to determine the number of available processors.

llvm-svn: 195172

llvm-svn: 195171

llvm-svn: 195170

llvm-svn: 195169

Summary:
RTTI is not yet implemented for the Microsoft C++ ABI and isn't expected
soon.  We could easily add the mangling, but the error is what prevents
us from silently miscompiling code that expects RTTI.

Instead, add a new mangleTypeName entry point that simply forwards to
mangleName or mangleType to produce a string that isn't part of the ABI.
Itanium can continue to use RTTI names to avoid unecessary test
breakage.

This also seems like the right design.  The fact that TBAA names happen
to be RTTI names is now an implementation detail of the mangler, rather
than part of TBAA.

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

llvm-svn: 195168

Emit DW_TAG_type_units into the debug_info section using compile unit
headers. This is bogus/unusable by debuggers, but testable and provides
more isolated review.

Subsequent patches will include support for type unit headers and
emission into the debug_types section, as well as comdat grouping the
types based on their hash. Also the CompileUnit type will be renamed
'Unit' and relevant portions pulled out into respective CompileUnit and
TypeUnit types.

llvm-svn: 195166

DebugInfo: Constify accelerator table handling, and separate type accelarator insertion in preparation for a second use of this code from type units.

llvm-svn: 195164

and we see an ill-formed declarator that would probably be well-formed if the
tag definition were just missing a semicolon, use that as the diagnostic
instead of producing some other mysterious error.

llvm-svn: 195163

We are slicing an array of Value pointers and process those slices in a loop.
The problem is that we might invalidate a later slice by vectorizing a former
slice.

Use a WeakVH to track the pointer. If the pointer is deleted or RAUW'ed we can
tell.

The test case will only fail when running with libgmalloc.

radar://15498655

llvm-svn: 195162