and expose it as a utility class rather than as free function wrappers.

The simple free-function interface works well for the bugpoint-specific
pass's uses of code extraction, but in an upcoming patch for more
advanced code extraction, they simply don't expose a rich enough
interface. I need to expose various stages of the process of doing the
code extraction and query information to decide whether or not to
actually complete the extraction or give up.

Rather than build up a new predicate model and pass that into these
functions, just take the class that was actually implementing the
functions and lift it up into a proper interface that can be used to
perform code extraction. The interface is cleaned up and re-documented
to work better in a header. It also is now setup to accept the blocks to
be extracted in the constructor rather than in a method.

In passing this essentially reverts my previous commit here exposing
a block-level query for eligibility of extraction. That is no longer
necessary with the more rich interface as clients can query the
extraction object for eligibility directly. This will reduce the number
of walks of the input basic block sequence by quite a bit which is
useful if this enters the normal optimization pipeline.

llvm-svn: 156163

This moves the logic for selecting a TLS model to a single place,
instead of the previous three (ARM, Mips, and X86 which already
uses this function).

llvm-svn: 156162

CC1 supports only the joined format.

llvm-svn: 156161

It reduces the amount of emitted debug information:
1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram,
DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only.
2) .debug_str contains only function names.
3) No debug data for types/namespaces/variables is emitted.
4) The data in .debug_line is enough to produce valid stack traces with
function names and line numbers.

Reviewed by Eric Christopher.

llvm-svn: 156160

llvm-svn: 156159

llvm-svn: 156158

llvm-svn: 156157

llvm-svn: 156156

Also combine the code in the 'assert' statement.

llvm-svn: 156155

llvm-svn: 156154

llvm-svn: 156153

This information in now computed by TableGen.

llvm-svn: 156152

This manually enumerated list of super-register classes has been
superceeded by the automatically computed super-register class masks
available through SuperRegClassIterator.

llvm-svn: 156151

using cmake+ninja, since ninja buffers the compiler output.

llvm-svn: 156150

llvm-svn: 156149

in the conditional.

llvm-svn: 156148

The masks returned by SuperRegClassIterator are computed automatically
by TableGen. This is better than depending on the manually specified
SuperRegClasses.

llvm-svn: 156147

The TargetLowering construction needs to use a valid TargetRegisterInfo
instance.

llvm-svn: 156146

rdar://11353109

llvm-svn: 156145

This iterator class provides a more abstract interface to the (Idx,
Mask) lists of super-registers for a register class. The layout of the
tables shouldn't be exposed to clients.

llvm-svn: 156144

llvm-svn: 156143

was removed in r155969 to address a deficiency of RecursiveASTVisitor
prior to recent changes on it.

llvm-svn: 156142

minimal disruption on its clients.

Unlike the previous data-recursive scheme, Traverse*Stmt methods are
always getting called. The base methods of RecursiveASTVisitor will enqueue
the sub-statements instead of calling TraverseStmt on them.

Clients that override a Traverse*Stmt method and call TraverseStmt will
still function as function-recursive traversal; if a client wants to
enqueue a sub-statement in its override method it can do it like this:

[inside the override method]
StmtQueueAction StmtQueue(*this);
StmtQueue.queue(Stmt->getSubStmt());

Should address rdar://11179167.

llvm-svn: 156141

minor behavior changes with this, but nothing I have seen evidence of in
the wild or expect to be meaningful. The real goal is unifying our logic
and simplifying the interfaces. A summary of the changes follows:

- Make 'callIsSmall' actually accept a callsite so it can handle
  intrinsics, and simplify callers appropriately.
- Nuke a completely bogus declaration of 'callIsSmall' that was still
  lurking in InlineCost.h... No idea how this got missed.
- Teach the 'isInstructionFree' about the various more intelligent
  'free' heuristics that got added to the inline cost analysis during
  review and testing. This mostly surrounds int->ptr and ptr->int casts.
- Switch most of the interesting parts of the inline cost analysis that
  were essentially computing 'is this instruction free?' to use the code
  metrics routine instead. This way we won't keep duplicating logic.

All of this is motivated by the desire to allow other passes to compute
a roughly equivalent 'cost' metric for a particular basic block as the
inline cost analysis. Sadly, re-using the same analysis for both is
really messy because only the actual inline cost analysis is ever going
to go to the contortions required for simplification, SROA analysis,
etc.

llvm-svn: 156140

recursive descent functions into one table driven parser.  Add proper
error recovery and reporting.  Add lots of test cases with semantics errors
and verify error messages.

llvm-svn: 156136

a struct.

llvm-svn: 156135

(Since we don't have a generic pointer escape callback, modify
ExprEngineCallAndReturn as well as the malloc checker.)

llvm-svn: 156134

of templates by using the newly introduce FoldingSetVector. This
preserves insertion order for all iteration of specializations.

I've also included a somewhat terrifying testcase that rapidly builds up
a large number of functions. This is enough that any system with ASLR
will have non-deterministic debug information generated for the test
case without the fix here as the debug information is generated in part
by walking these specializations.

llvm-svn: 156133

llvm-svn: 156132

but using a FoldingSet underneath and with a largely compatible
interface to that of FoldingSet. This can be used anywhere a FoldingSet
would be natural, but iteration order is significant. The initial
intended use case is in Clang's template specialization lists to
preserve instantiation order iteration.

llvm-svn: 156131

llvm-svn: 156130

Inline DenseMapInfo<clang::DeclarationName>::getHashValue() for a 0.4% speedup on <rdar://problem/11004361>

llvm-svn: 156129

Patch by Meador Inge.

llvm-svn: 156128

// rdar://11095151

llvm-svn: 156127

(trivially) make DeclContext::lookup()'s const version inlinable. Good
for 0.3% on <rdar://problem/11004361>.

llvm-svn: 156126

synthesis translation. // rdar://11374235 - wip.

llvm-svn: 156125

llvm-svn: 156124

llvm-svn: 156123

TargetRegisterClass now gives access to the necessary tables.

llvm-svn: 156122

This is a pointer into one of the tables used by
getMatchingSuperRegClass(). It makes it possible to use a shared
implementation of that function.

llvm-svn: 156121