llvm-svn: 143564

llvm-svn: 143563

llvm-svn: 143562

llvm-svn: 143561

allows us to set __attribute__ ((used)) on expressions
that masquerade as methods.  When we are stopped in
classes in anonymous namespaces, this fix (and enabling
__attribute__ ((used)) on the method) will allow
expressions to run.

llvm-svn: 143560

llvm-svn: 143559

Fix the issue that r143552 was trying to address the _right_ way.  One-register lists are legal on LDM/STM instructions, but we should not print the PUSH/POP aliases when they appear.  This fixes round tripping on this instruction.

llvm-svn: 143557

Thanks to Nick for spotting this!

llvm-svn: 143556

longer need substitutions for.

llvm-svn: 143555

So far added the skeleton + several more or less complete sections:
Getting Started
Idea for a Checker
AST Visitors
Useful Commands/Debugging Hints

llvm-svn: 143554

The rules disallowing single-register reglist operands only apply to the POP alias, not to LDM/STM instructions.  Revert r143552.

llvm-svn: 143553

Register list operands are not allowed to contain only a single register.  Alternate encodings are used in that case.

llvm-svn: 143552

the injected-class-name of a class (or class template) to the
declaration that results from substituting the given template
arguments. Previously, we would actually perform a substitution into
the injected-class-name type and then retrieve the resulting
declaration. However, in certain, rare circumstances involving
deeply-nested member templates, we would get the wrong substitution
arguments.

This new approach just matches up the declaration with a declaration
that's part of the current context (or one of its parents), which will
either be an instantiation (during template instantiation) or the
declaration itself (during the definition of the template). This is
both more efficient (we're avoiding a substitution) and more correct
(we can't get the template arguments wrong in the member-template
case). 

Fixes <rdar://problem/9676205>.

llvm-svn: 143551

Use StringLiteral::getBytes(), not StringLiteral::getString(), when profiling the expression, so that it works for non-UTF8 strings.

llvm-svn: 143550

llvm-svn: 143549

to force it to build after all library targets so it has complete
dependency information. This should fix broken 'make install' with
CMake.

This is a partial revert of r143540, but it doesn't revert the most
important part of that change: removing the dependency edge from LLVM
tools to the llvm-config script.

llvm-svn: 143548

llvm-svn: 143547

We've been hitting asserts in this code due to the many supported
combintions of modes (iv-rewrite/no-iv-rewrite) and IV types. This
second rewrite of the code attempts to deal with these cases systematically.

llvm-svn: 143546

working today, but it shouldn't corrupt state for some poor soul to
debug later.

llvm-svn: 143545

llvm-svn: 143544

documentation.

llvm-svn: 143543

particularly useful.

llvm-svn: 143542

llvm-svn: 143541

llvm-config build, there is no longer a point to this after Chandler's work.

llvm-svn: 143540

llvm-svn: 143539

llvm-svn: 143538

the mailing list. Suggestions for other statistics to collect would be
awesome. =]

Currently these are implemented as a separate pass guarded by a separate
flag. I'm not thrilled by that, but I wanted to be able to collect the
statistics for the old code placement as well as the new in order to
have a point of comparison. I'm planning on folding them into the single
pass if / when there is only one pass of interest.

llvm-svn: 143537

llvm-svn: 143536

llvm-svn: 143535

silence -Wparentheses.

llvm-svn: 143534

The -g and --gdwarf2 options are currently synonyms to the Darwin assembler.
But clang itself does not recognize --gdwarf2, so if we want to experiment
with using clang, with its integrated assembler, to replace the default
assembler, it is necessary to use -g.  <rdar://problem/10349486>

llvm-svn: 143533

depends on the Support library rather than relying on TableGen's
transitive dependency.

llvm-svn: 143532

one aspect of them by having them use the (annoying, if not broken)
proper library dependency model for adding the LLVMTableGen library as
a dependency. This could manifest as a link order issue in the presence
of separate LLVM / Clang source builds with CMake and a linker that
really cares about such things.

Also, add the Support dependency to llvm-tblgen itself so that it
doesn't rely on TableGen's transitive Support dependency. A parallel
change for clang-tblgen will be forthcoming.

llvm-svn: 143531

llvm-svn: 143530

llvm-svn: 143529

Fixed an issue where the DWARF might mention that a class has a constructor
(default, copy or move), destructor, or an assignment operator (copy or move)
and it might not have an actual implementation in your code. Then you try and
use this struct or class in an expression and the JIT would ask for the 
address of these methods that were in the declaration, yet there are none.
We now "do the right thing" for trivial ctors, dtors and assignment operators
by telling the methods that they are are defaulted and trivial, and clang will
then just do all of the work with builtins!

llvm-svn: 143528

<rdar://problem/10374763>

llvm-svn: 143527

generated special member functions (constructors,
destructors, etc.) for classes that don't really have
them.  We needed to mark these as artificial to reflect
the debug information; this bug does that for
constructors and destructors.

The "etc." case (certain assignment operators, mostly)
remains to be fixed.

llvm-svn: 143526

llvm-svn: 143525

Add support to the linker to lazily link in functions. This change only links functions marked with specific linkage (internal, private, linker_private, linker_private_weak, linker_private_weak_def_auto, linkonce, linkonce_odr, and available_externally) if they have uses in the destination module. Instead of automatically linking, these functions are placed onto a worklist to be processed in the final stage of linking. We iterate over the list and if any functions on the list have uses in the destination module, we link them in and repeat the process until no changes in the state (uses) has changed. This means that any functions in the LazilyLink worklist that have a use in the destination module will be linked in and none that don't. 

llvm-svn: 143524