The *Impl class no longer serves a purpose now that the super-class
implementation is in CodeGen.

llvm-svn: 168759

The Target library is not allowed to depend on the large CodeGen
library, but the TRI and TII classes provide abstract interfaces that
require both caller and callee to link to CodeGen.

The implementation files for these classes provide default
implementations of some of the hooks. These methods may need to
reference CodeGen, so they belong in that library.

We already have a number of methods implemented in the
TargetInstrInfoImpl sub-class because of that. I will merge that class
into the parent next.

llvm-svn: 168758

The stop-gap here is to just drop such objects when processing the InitListExpr.
We still need a better solution.

Fixes <rdar://problem/12755044>.

llvm-svn: 168757

arc specific diagnostic on the selector. This is objc-arc
part of // rdar://11303469

llvm-svn: 168756

llvm-svn: 168755

Simplify the logging on ObjectFile::~ObjectFile() to not access an classes above the object file (like the module) so we don't crash when logging object lifetimes. The log message contains the "this" pointer value which can be matched up with the constructor log.

llvm-svn: 168754

llvm-svn: 168752

llvm-svn: 168751

llvm-svn: 168750

 - Also, support overriding them with lit parameters.

llvm-svn: 168749

llvm-svn: 168748

When the CodeGenInfo is to be created for the PPC64 target machine,
a default code-model selection is converted to CodeModel::Medium
provided we are not targeting the Darwin OS.  Defaults for Darwin
are unaffected.

llvm-svn: 168747

DebugClang builds of LLDB to build a properly
codesigned debugserver.  I did this by adding
a DebugClang configuration to debugserver that's
just a clone of the Debug configuration.

llvm-svn: 168746

Suggested by Sean McBride, thanks!

llvm-svn: 168745

Suggested by Sean McBride, thanks!

llvm-svn: 168744

Make sure that ValueObjectDynamicValue clears itself when no dynamic type information can be found
This behavior was supposed to be already happening (as per the comment lines)

llvm-svn: 168743

This was also covered by <rdar://problem/12753384>.  The static analyzer
evaluates a CXXConstructExpr within an initializer expression and
RegionStore doesn't know how to handle the resulting CXXTempObjectRegion
that gets created.  We need a better solution than just dropping the
value, but we need to better understand how to implement the right
semantics here.

Thanks to Jordan for his help diagnosing the behavior here.

llvm-svn: 168741

objc_loadWeak. This retains and autorelease the weakly-refereced
object. This hidden autorelease sometimes makes __weak variable alive even
after the weak reference is erased, because the object is still referenced
by an autorelease pool. This patch overcomes this behavior by loading a 
weak object via call to objc_loadWeakRetained(), followng it by objc_release
at appropriate place, thereby removing the hidden autorelease. // rdar://10849570

llvm-svn: 168740

llvm-svn: 168739

No functionality change.

llvm-svn: 168738

the coding standard would like.

llvm-svn: 168737

llvm-svn: 168736

classes.  The vast majority of the remaining issues are due to uses of
invalid registers, which are defined by getRegForValue().  Those will be
a little more challenging to cleanup.
rdar://12719844

llvm-svn: 168735

Properly detect the if unnamed bitfields are supported by clang if the major calng version is higher than 425.

llvm-svn: 168734

classes.
rdar://12719844

llvm-svn: 168733

r128056 moved PrettyStackTraceParserEntry construction from Parser.h
to ParseAST.cpp, so there's no need to keep this class in a header.

llvm-svn: 168731

llvm-svn: 168729

classes.  Also a bit of cleanup.
rdar://12719844

llvm-svn: 168728

llvm-svn: 168727

by Olivier Goffart!

llvm-svn: 168726

add some assertions. No functionality change.

llvm-svn: 168725

llvm-svn: 168724

llvm-svn: 168723

The functionality of SectionMemoryManager is equivalent to the LLIMCJITMemoryManager being replaced except that it allocates memory as RW and later changes it to RX or R as needed.  The page permissions are set in the call to MCJIT::finalizeObject.

llvm-svn: 168722

The SectionMemoryManager now supports (and requires) applying section-specific page permissions.  Clients using this memory manager must call either MCJIT::finalizeObject() or SectionMemoryManager::applyPermissions() before executing JITed code.

See r168718 for changes from the previous implementation.

llvm-svn: 168721

Make use of unix system calls to provide physical memory usage profile data.

llvm-svn: 168720

there's no possible loo-independent dependence, then there's no
dependence.

Updated all test result appropriately.

llvm-svn: 168719

This commit is primarily here for the revision history.  I'm about to move the SectionMemoryManager into the RuntimeDyld library, but I wanted to check the changes in here so people could see the differences in the updated implementation.

llvm-svn: 168718

boundaries.

Given the following case:
BB0
  %vreg1<def> = SUBrr %vreg0, %vreg7
  %vreg2<def> = COPY %vreg7
BB1
  %vreg10<def> = SUBrr %vreg0, %vreg2
We should be able to CSE between SUBrr in BB0 and SUBrr in BB1.

rdar://12462006

llvm-svn: 168717

My commit to migrate the printf simplifiers from the simplify-libcalls
in r168604 introduced a regression reported by Duncan [1].  The problem
is that in some cases the library call simplifier can return a new value
that has no uses and the new value's type is different than the old value's
type (which is fine because there are no uses).  The specific case that
triggered the bug looked something like:

   declare void @printf(i8*, ...)
   ...
   call void (i8*, ...)* @printf(i8* %fmt)

Which we want to optimized into:

   call i32 @putchar(i32 104)

However, the code was attempting to replace all uses of the printf with
the putchar and the types differ, hence a crash.  This is fixed by *just*
deleting the original instruction when there are no uses.  The old
simplify-libcalls pass is already doing something similar.

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-November/056338.html

llvm-svn: 168716