Since the analysis managers were split into explicit function and module
analysis managers, it is now completely trivial to specify this when
building up the concept and model types explicitly, and it is impossible
to end up with a type error at run time. We instantiate a template when
registering a pass that will enforce the requirement at a type-system
level, and we produce a dynamic error on all the other query paths to
the analysis manager if the pass in question isn't registered.

llvm-svn: 195447

Sorry for the noice.

llvm-svn: 195446

This is supposed to be the whole type of the IR unit, and so we
shouldn't pass a pointer to it but rather the value itself. In turn, we
need to provide a 'Module *' as that type argument (for example). This
will become more relevant with SCCs or other units which may not be
passed as a pointer type, but also brings consistency with the
transformation pass templates.

llvm-svn: 195445

[mips][msa] Float vector constants cannot use ldi.[wd] directly. Bitcast from the appropriate integer vector type.

Fixes an instruction selection failure detected by llvm-stress.

llvm-svn: 195444

llvm-svn: 195443

llvm-svn: 195442

Summary:
Call real pthread_attr_getstack instead of the interceptor
when we do intercept pthread_attr_getstack.

Reviewers: samsonov, eugenis

Reviewed By: samsonov

CC: llvm-commits

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

llvm-svn: 195441

llvm-svn: 195440

llvm-svn: 195439

Not long ago I made the CodeGen of for loops simplify the condition at
-O0 in the same way we do for if and conditionals. Unfortunately this
ties how loops and simple conditions work together too tightly, which
makes features such as instrumentation based PGO awkward.

Ultimately, we should find a more general way to simplify the logic in
a given condition, but for now we'll just avoid using EmitBranchOnBool
for loops, like we already do for while and do loops.

llvm-svn: 195438

llvm-svn: 195437

llvm-svn: 195436

0 as CPU subtype never matches anything (at least, it doesn't match x86_64 windows binaries, of which there are correct arch definitions for). It should be created with LLDB_INVALID_CPUTYPE. 

llvm-svn: 195435

This time in a forward/backward compatible way.

llvm-svn: 195434

llvm-svn: 195433

Fix a Cygwin build failure caused by enum values starting with '_', which is conflicted with some platform macros.    
This patch only renames variables, no functional change.

llvm-svn: 195432

 type_traits:3280:31: error: expected primary-expression before 'decltype'
 type_traits:3280:29: error: expected ';' at end of member declaration

 memory:2415:49: error: function 'std::__1::default_delete<_Tp>::default_delete()'
 defaulted on its first declaration must not have an exception-specification

 memory:2435:49: error: function 'std::__1::default_delete<_Tp []>::default_delete()'
 defaulted on its first declaration must not have an exception-specification

The attached patch defines _LIBCPP_HAS_NO_ADVANCED_SFINAE and 
_LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS for gcc version < 4.7, making
the library compile with gcc 4.6.4.

llvm-svn: 195431

Deleting three tests that are redundant with test/Preprocessor/arm-target-features.c and test/Driver/arm-cortex-cpus.c

llvm-svn: 195430

Some linux headers are broken on older kernels.
Instead of depending on the constants and types from such headers directly,
we provide our own definitions and then verify them with compile-time
assertions. This makes the dependency on the headers test-only and would allow
switching to some other way of testing on older kernels, or even disable the
tests as the last resort (after all, kernel interfaces are supposed to be
stable).

llvm-svn: 195427

can't accidentally be allocated the wrong way (missing prefix data for decls
from AST files, for instance) and simplifies the CreateDeserialized functions a
little. An extra DeclContext* parameter to the not-from-AST-file operator new
allows us to ensure that we don't accidentally call the wrong one when
deserializing (when we don't have a DeclContext), allows some extra checks, and
prepares for some planned modules-related changes to Decl allocation.

No functionality change intended.

llvm-svn: 195426

llvm-svn: 195425

e.g. "%tmp = load <2 x i64>* %ptr" can't be selected. 
     "%tmp = bitcast i64 %in to <2 x i32>" can't be selected.

llvm-svn: 195424

llvm-svn: 195423

Diags aren't usually in the first person, and 'windows' isn't the correct
product spelling to use in prose. Sidestep issues completely by making this
error message platform-neutral.

llvm-svn: 195422

Fix a Cygwin build failure caused by enum values starting with '_', which is conflicted with some platform macros.
This solution only renames variables, no functional change.

NOTE: This is a candidate for the 3.4 branch.
llvm-svn: 195421

This matches other README.txt files in LLVM and makes things more obvious on
Windows where it's likely to be read. CRLFs are retained for the same reason.

Also fix Visual Studio product name.

llvm-svn: 195420

ASTUnit instances are allocated infrequently so it's fine to keep this field
around in all build configurations.

Assigns null to silence -Wunused-private-field in Release.

llvm-svn: 195419

Before:
  template <typename aaaaaaaaaaa, typename bbbbbbbbbbbbb, template <typename>
            class cccccccccccccccccccccc, typename ddddddddddddd>
  class C {};

After:
  template <typename aaaaaaaaaaa, typename bbbbbbbbbbbbb,
            template <typename> class cccccccccccccccccccccc,
            typename ddddddddddddd>
  class C {};

llvm-svn: 195418

Before:
  int count = set<int> { f(), g(), h() }
      .size();

After:
  int count = set<int>{f(), g(), h()}.size();

llvm-svn: 195417

llvm-svn: 195411

We already have a method for returning one loop latch but for some
reason no one has committed one for returning loop latches in the case
where there are multiple latches.

llvm-svn: 195410

llvm-svn: 195409

llvm-svn: 195408

They failed on bdver2 buildslave.

FIXME: FileCheck-ize them.
llvm-svn: 195407

llvm-svn: 195406

It was there all the time, but I missed adding a RUN line for it.

llvm-svn: 195405

the code that should have set thread names on Mac OS X.

<rdar://problem/15517264>

llvm-svn: 195403

factoring it out into the default template argument so clients don't
have to even think about it.

llvm-svn: 195402

<def,dead> ones.

Add an assertion to make sure we catch this in the future.

Fixes <rdar://problem/15464559>.

llvm-svn: 195401

rather than the constructors of passes.

This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.

I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.

Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.

Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:

{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy

(except for XAnalysisManagerXProxy which doesn't make any sense)

This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.

After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!

llvm-svn: 195400