Sicne MBB->computeRegisterLivenes() returns Dead for sub regs like s0,
d0 is used in vpop instead of updating sp, which causes s0 dead before
its use.

This patch checks the liveness of each subreg to make sure the reg is
actually dead.

llvm-svn: 204411

Patch by Ted Woodward

llvm-svn: 204409

Variables with available_externally linkage can be dropped at will.
This causes link errors, since there are still references to the
instrumentation!  linkonce_odr is almost equivalent, so use that
instead.

As a drive-by fix (I don't have an Elf system, so I'm not sure how to
write a testcase), use linkonce linkage for the instrumentation of
extern_weak functions.

<rdar://problem/15943240>

llvm-svn: 204408

The variable is used to set the linkage for variables, and will become
different from function linkage in a follow-up commit.

<rdar://problem/15943240>

llvm-svn: 204407

llvm-svn: 204406

It was dead.

llvm-svn: 204404

resolved, emit an update record.

llvm-svn: 204403

llvm-svn: 204402

llvm-svn: 204401

Switch over to use the ArchSpec::GetMachine() instead of ArchSpec::GetCore() to keep the code more portable as we add new core types to ArchSpec.

llvm-svn: 204400

The function exists to force an expression to be absolute, but there it is not
possible to force a symbol reference since

a = b
.long a

means something else.

This is an alternative fix for pr9951 that uses an assert. It then deletes
the old pr9951 test that was testing nothing already.

llvm-svn: 204399

RTDyldMemoryManager, regardless of whether it thinks they're "required for
execution".

Currently, RuntimeDyld only passes sections that are "required for execution"
to the RTDyldMemoryManager, and takes "required for execution" to mean exactly
"contains symbols or relocations". There are two problems with this:
(1) It can drop sections with anonymous data that is referenced by code.
(2) It leaves the JIT client no way to inspect interesting sections that aren't
    actually required to run the program (e.g dwarf sections).

A test case is still in the works.

Future work: We may want to replace this with a generic section filtering
mechanism, but that will require more consideration. For now, this flag at least
allows clients to volunteer to do the filtering themselves.

Fixes <rdar://problem/15177691>.

llvm-svn: 204398

llvm-svn: 204397

It turns out this is C code.  Specify foo(void).

<rdar://problem/15943240>

llvm-svn: 204396

llvm-svn: 204395

Fix PR19172 - wrong this adjustment calculated for virtual destructor in a class with complex inheritance

Reviewed at http://llvm-reviews.chandlerc.com/D3128

llvm-svn: 204394

I will break this up into smaller pieces for review and recommit.

llvm-svn: 204393

llvm-svn: 204392

These functions are in the profile runtime.  PGO comes later.

Unfortunately, there's only room for 16 characters in a Darwin section,
so use __llvm_prf_ instead of __llvm_profile_ for section names.

<rdar://problem/15943240>

llvm-svn: 204391

These functions are in the profile runtime.  PGO comes later.

Unfortunately, there's only room for 16 characters in a Darwin section,
so use __llvm_prf_ instead of __llvm_profile_ for section names.

<rdar://problem/15943240>

llvm-svn: 204390

This commit extends the coverage of the constant hoisting pass, adds additonal
debug output and updates the function names according to the style guide.

Related to <rdar://problem/16381500>

llvm-svn: 204389

This option caused LowerInvoke to generate code using SJLJ-based
exception handling, but there is no code left that interprets the
jmp_buf stack that the resulting code maintained (llvm.sjljeh.jblist).
This option has been obsolete for a while, and replaced by
SjLjEHPrepare.

This leaves the default behaviour of LowerInvoke, which is to convert
invokes to calls.

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

llvm-svn: 204388

llvm-svn: 204387

Adding __llvm_pgo_reset_counters(), which sets all the counters to 0.

<rdar://problem/15943240>

llvm-svn: 204386

block as decl and type emission. This allows decl updates include statements
and expressions. No functionality change (but the generated PCM files are
incompatible with earlier versions of Clang).

llvm-svn: 204385

llvm-svn: 204384

__llvm_pgo_write_default_file() was a bad name, since it checked the
environment (it wasn't just a default file).

  - Change __llvm_pgo_write_file() to __llvm_pgo_write_file_with_name()
    and make it static.

  - Rename __llvm_pgo_write_default_file() to __llvm_pgo_write_file().

  - Add __llvm_pgo_set_filename(), which sets the filename for
    subsequent calls to __llvm_pgo_write_file().

<rdar://problem/15943240>

llvm-svn: 204381

Instead of relying on explicit static initialization from translation
units, create a new file, InstrProfilingRuntime.cc, with an
__llvm_pgo_runtime variable.  After this commit (and its pair in clang),
the driver will create a use of this variable.  Unless the user defines
their own version, the new object file will get pulled in, including
that C++ static initialization that calls
__llvm_pgo_register_write_atexit.

The result is that, at least on Darwin, static initialization typically
consists of a single function call, which registers a writeout functino
atexit.  Furthermore, users can skip even this behaviour by defining
their own __llvm_pgo_runtime.

<rdar://problem/15943240>

llvm-svn: 204380

Remove the remaining explicit static initialization from translation
units, at least on Darwin.  Instead, create a use of __llvm_pgo_runtime,
which will pull in required code from compiler-rt.

After this commit (and its pair in compiler-rt), a user can define their
own __llvm_pgo_runtime to satisfy this undefined symbol and call the
functions in compiler-rt directly.

<rdar://problem/15943240>

llvm-svn: 204379

llvm-svn: 204378

    Use the range machinery for DW_AT_ranges and DW_AT_high/lo_pc.

    This commit moves us from a single range per subprogram to extending
    ranges if we are:

    a) In the same section, and
    b) In the same enclosing CU.

    This means we have more fine grained ranges for compile units, and fewer
    ranges overall when we have multiple functions in the same CU
    adjacent to each other in the object file.

    Also remove all of the earlier hacks around this functionality for
    function sections etc. Also update all of the testcases to take into
    account the merging functionality.

with a fix for location entries in the debug_loc section:

Make sure that debug loc entries are relative to the low_pc
of the compile unit. This means that when we only have a single
range that the offset should be just relative to the low_pc
of the unit, for multiple ranges for a CU this means that we'll be
relative to 0 which we emit along with DW_AT_ranges.

This mostly shows up with linked binaries, so add a testcase with
multiple CUs so that our location is going to be offset of a CU
with a non-zero low_pc.

llvm-svn: 204377

llvm-svn: 204376

llvm-svn: 204375

[analyzer] Fix a bad bug in reversePropagateInterstingSymbols() where only one subexpression of BinaryOperator would be explored.

llvm-svn: 204374

<rdar://problem/15943240>

llvm-svn: 204373

llvm-svn: 204372

llvm-svn: 204371

llvm-svn: 204370

llvm-svn: 204369

We were 'allowing' the following import
@import Sub;

where Sub is a subframework of Foo and we had a -F path inside
Foo.framework/Frameworks and no module map file for Sub. This would
later hit assertion failures in debug builds.

Now we should correctly diagnose this as a module not found error.

llvm-svn: 204368