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

llvm-svn: 143523

Narrowest possible fix for PR11279.

llvm-svn: 143522

it is separating the directory part from the basename of the FileName.  Noticed 
that this:

  .file 1 "dir/foo"

when assembled got the two parts switched.  Using the Mac OS X dwarfdump tool
it can be seen easily:

% dwarfdump -a a.out
include_directories[  1] = 'foo'
                Dir  Mod Time   File Len   File Name
                ---- ---------- ---------- ---------------------------
file_names[  1]    1 0x00000000 0x00000000 dir
...

Which should be:
...
include_directories[  1] = 'dir'
                Dir  Mod Time   File Len   File Name
                ---- ---------- ---------- ---------------------------
file_names[  1]    1 0x00000000 0x00000000 foo

llvm-svn: 143521

correctly, and added a testcase to check that it works.

The main problem here is that Objective-C class method
selectors are external references stored in a special
data structure in the LLVM IR module for an expression.
I just had to extract them and ensure that the real
class object locations were properly resolved.

llvm-svn: 143520

llvm-svn: 143519

// rdar://10357768

llvm-svn: 143518

This prevents caching out on nodes with different sink flag.
(This is a cleaner fix for radar://10376675).

llvm-svn: 143517

This is another fallout from the refactoring. We were
calling MarkAsSink on a cached out node.
(Fixes radar://10376675)

llvm-svn: 143516

The parent and child builders should not share node sets.

llvm-svn: 143515

This fixes radar://10367606

llvm-svn: 143514

Remove unnecessary calls to CheckerContext::getPredecessor() + Comments.

llvm-svn: 143513

llvm-svn: 143512

For example, labels from Objective-C sources.

llvm-svn: 143511

llvm-svn: 143510

-g flag.  In this part we generate the .file for the source being assembled and
the .loc's for the assembled instructions.

The next part will be to generate the dwarf Compile Unit DIE and a dwarf
subprogram DIE for each non-temporary label.

Once the next part is done test cases will be added.  rdar://9275556

llvm-svn: 143509

llvm-svn: 143508

llvm-svn: 143507