This is the first patch in a series of 3 patches which clean up how we create
runtime function declarations in the ARC optimizer when they do not exist
already in the IR.

Currently we have a bunch of duplicated code in ObjCARCOpts, ObjCARCContract
that does this. This patch refactors that code into a separate class called
ARCRuntimeEntryPoints which lazily creates the declarations for said
entrypoints.

The next two patches will consist of the work of refactoring
ObjCARCContract/ObjCARCOpts to use this new code.

llvm-svn: 185740

llvm-svn: 185739

llvm-svn: 185738

llvm-svn: 185737

llvm-svn: 185736

functions. Make the function attributes pass add it to known library functions
and when it can deduce it.

llvm-svn: 185735

class type. // rdar://14261999

llvm-svn: 185734

No functional change intended.

llvm-svn: 185733

use can cause crash. No test is available. It is uncovered
by code browsing.  // rdar://14348205

llvm-svn: 185732

llvm-svn: 185731

llvm-svn: 185730

llvm-svn: 185729

llvm-svn: 185728

Include a test that clang now produces output files with permissions matching
the umask.

llvm-svn: 185727

This function is complementary to createTemporaryFile. It handles the case were
the unique file is *not* temporary: we will rename it in the end. Since we
will rename it, the file has to be in the same filesystem as the final
destination and we don't prepend the system temporary directory.

This has a small semantic difference from unique_file: the default mode is 0666.
This matches the behavior of most unix tools. For example, with this change
lld now produces files with the same permissions as ld. I will add a test
of this change when I port clang over to createUniqueFile (next commit).

llvm-svn: 185726

llvm-svn: 185725

use of objc's properties.

llvm-svn: 185724

llvm-svn: 185723

[libclang] Introduce clang_Cursor_isObjCOptional, which returns whether the declaration was affected by "@optional"

rdar://14348525.

llvm-svn: 185722

This changes the TBAA code so it doesn't use mangleCXXRTTIName in C,
because it doesn't really make sense there.  Also, as sort of a
defense-in-depth change, fix the mangler so it handles C RecordDecls
correctly.

No tests because I don't know the TBAA code well enough to write a test,
and I don't know how else to trigger mangling a local struct in C.

Fixes a crash with r185450 reported by Joerg Sonnenberger.

llvm-svn: 185721

reenabled reverted patch after checking that it passes without regressions on
the nightly test-suite.  Added testcase from Tobi.

llvm-svn: 185720

llvm-svn: 185719

llvm-svn: 185718

llvm-svn: 185717

This function is inspired by clang's Driver::GetTemporaryPath. It hides the
pattern used for uniquing and requires simple file names that are always
placed in the system temporary directory.

llvm-svn: 185716

llvm-svn: 185715

llvm-svn: 185714

As it turns out, the NoFunction bit for local class mangling needed to be
propagated into more places. r185450 turned what used to be an incorrect
mangling into an assertion.

llvm-svn: 185713

A "pkhtb x, x, y asr #num" uses the lower 16 bits of "y asr #num" and packs them
in the bottom half of "x". An arithmetic and logic shift are only equivalent in
this context if the shift amount is 16. We would be shifting in ones into the
bottom 16bits instead of zeros if "y" is negative.

radar://14338767

llvm-svn: 185712

Remove implicit conversion from __value_type to value_type in [unordered_][multi]map.  This fixes http://llvm.org/bugs/show_bug.cgi?id=16549

llvm-svn: 185711

abstract class type. // rdar://14261999

llvm-svn: 185710

llvm-svn: 185709

llvm-svn: 185708

We should not be asking unique_file to prepend the system temporary directory
when creating the html report. Unfortunately I don't think we can test this
with the current infrastructure since unique_file ignores MakeAbsolute if the
directory is already absolute and the paths provided by lit are.

I will take a quick look at making this api a bit less error prone.

llvm-svn: 185707

llvm-svn: 185706

The stack coloring pass has code to delete stores and loads that become
trivially dead after coloring.  Extend it to cope with single instructions
that copy from one frame index to another.

The testcase happens to show an example of this kicking in at the moment.
It did occur in Real Code too though.

llvm-svn: 185705

This fixes foldMemoryOperandImpl() so that it doesn't create duplicated
frame MMOs.  I hadn't realized when writing r185434 that it was the caller's
responsibility to add these.

No behavioural change intended.

llvm-svn: 185704

The stack coloring pass renumbered frame indexes with a loop of the form:

  for each frame index FI
    for each instruction I that uses FI
      for each use of FI in I
        rename FI to FI'

This caused problems if an instruction used two frame indexes F0 and F1
and if F0 was renamed to F1 and F1 to F2.  The first time we visited the
instruction we changed F0 to F1, then we changed both F1s to F2.

In other words, the problem was that SSRefs recorded which instructions
used an FI, but not which MachineOperands and MachineMemOperands within
that instruction used it.

This is easily fixed for MachineOperands by walking the instructions
once and processing each operand in turn.  There's already a loop to
do that for dead store elimination, so it seemed more efficient to
fuse the two at the block level.

MachineMemOperands are more tricky because they can be shared between
instructions.  The patch handles them by making SSRefs an array of
MachineMemOperands rather than an array of MachineInstrs.  We might end
up processing the same MachineMemOperand twice, but that's OK because
we always know from the SSRefs index what the original frame index was.

llvm-svn: 185703

The operator== calls equivalent which calls default_error_condition which
handles windows to posix conversion.

llvm-svn: 185702

...now that the problem that prompted the restriction has been fixed.

The original spill-02.py was a compromise because at the time I couldn't
find an example that actually failed without the two scavenging slots.
The version included here did.

llvm-svn: 185701