CUs.

Currently only hashes the name of CUs and the names of any children,
but it's an obvious first step to show the framework. The testcase
should continue to be correct, however, as it's an empty TU.

llvm-svn: 188243

to find loops if the From and To instructions were in the same block.

Refactor the code a little now that we need to fill to start the CFG-walking
algorithm with more than one starting basic block sometimes.

Special thanks to Andrew Trick for catching an error in my understanding of
natural loops in code review.

llvm-svn: 188236

llvm-svn: 188234

llvm-svn: 188233

llvm-svn: 188232

e.g. Use Ty->getPointerElementType()
instead of cast<PointerType>(Ty)->getElementType()

llvm-svn: 188223

FileCheck should check to make sure the prefix was found, and not a word
containing it (e.g -check-prefix=BASEREL shouldn't match NOBASEREL).

Patch by Ron Ofir.

llvm-svn: 188221

llvm-svn: 188220

llvm-svn: 188219

undefined and produce an error message instead as this is a non-relocatable
expression with X86 Mach-O.

rdar://8920876

llvm-svn: 188218

llvm-svn: 188217

llvm-svn: 188216

R600 doesn't need to do any scheduling on the SelectionDAG now that it
has a very good MachineScheduler.  Also, using the VLIW SelectionDAG
scheduler was having a major impact on compile times. For example with
the phatk kernel here are the LLVM IR to machine code compile times:

With Sched::VLIW

Total Compile Time:                  1.4890 Seconds (User + System)
SelectionDAG Instruction Scheduling: 1.1670 Seconds (User + System)

With Sched::Source

Total Compile Time:                  0.3330 Seconds (User + System)
SelectionDAG Instruction Scheduling: 0.0070 Seconds (User + System)

The code ouput was identical with both schedulers.  This may not be true
for all programs, but it gives me confidence that there won't be much
reduction, if any, in code quality by using Sched::Source.

llvm-svn: 188215

llvm-svn: 188205

In order to appease people (in Apple) who accuse me for committing "huge change" (?) without proper review. 

Thank Eric for fixing a compile-warning. 

llvm-svn: 188204

llvm-svn: 188203

llvm-svn: 188202

llvm-svn: 188201

llvm-svn: 188200

has been finalized except for sizes and offsets. Update test accordingly.

llvm-svn: 188199

llvm-svn: 188198

llvm-svn: 188195

We support this libcall on all platforms except for OpenBSD (See
lib/Codegen/StackProtector.cpp).

llvm-svn: 188193

llvm-svn: 188191

  1. Add some helper classes for partitions. They are designed in a
     way such that the top-level LTO driver will not see much difference 
     with or without partitioning.

  2. Introduce work-dir. Now all intermediate files generated during 
     LTO phases will be saved under work-dir. User can specify the workdir
     via -lto-workdir=/path/to/dir. By default the work-dir will be 
     erased before linker exit. To keep the workdir, do -lto-keep, or -lto-keep=1.

    TODO: Erase the workdir, if the linker exit prematurely.  
      We are currently not able to remove directory on signal. The support 
      routines simply ignore directory.

  3. Add one new API lto_codegen_get_files_need_remove().
     Linker and LTO plugin will communicate via this API about which files
    (including directories) need to removed before linker exit.

llvm-svn: 188188

Do not generate new vector values for the same entries because we know that the incoming values
from the same block must be identical.

llvm-svn: 188185

This fixes the incorrect implementation of iterating on file/directory
paths.

Differential Review: http://llvm-reviews.chandlerc.com/D1277

llvm-svn: 188183

llvm-svn: 188176

Various tests had sprung up over the years which had --check-prefix=ABC on the
RUN line, but "CHECK-ABC:" later on. This happened to work before, but was
strictly incorrect. FileCheck is getting stricter soon though.

Patch by Ron Ofir.

llvm-svn: 188173

llvm-svn: 188171

llvm-svn: 188169

Apparently caused a failure on Darwin

llvm-svn: 188166

curses.h). Finding these headers is next to impossible. For example, on
Debian systems libtinfo-dev provides the terminfo reading library we
want, but *not* term.h. For the header, you have to use libncurses-dev.
And libncursesw-dev provides a *different* term.h in a different
location!

These headers aren't worth it. We want two functions the signatures of
which are clearly spec'ed in sys-v and other documentation. Just declare
them ourselves and call them. This should fix some debian builders and
provide better support for "minimal" debian systems that do want color
autodetection.

llvm-svn: 188165

clang bootstraps intermittently failed for me due a difference in
the MCK_Reg ordering in ARMGenAsmMatcher.inc.  E.g. in my latest
run the stage 1 and stage 3 versions were the same but the stage 2
one was different (though still functionally correct).  This meant
that the .o comparison failed.

MCK_Regs were assigned by iterating over a std::set< std::set<Record*> >,
and since std::set is sorted lexicographically, the order depended on the
order of the pointer values.  This patch replaces the pointer ordering
with LessRecordByID.

llvm-svn: 188164

For now this is restricted to fixed-length comparisons with a length
in the range [1, 256], as for memcpy() and MVC.

llvm-svn: 188163

llvm-svn: 188162

llvm-svn: 188161

library for color support detection. This still will use a curses
library if that is all we have available on the system. This change
tries to use a smaller subset of the curses library, specifically the
subset that is on some systems split off into a separate library. For
example, if you install ncurses configured --with-tinfo, a 'libtinfo' is
install that provides just the terminfo querying functionality. That
library is now used instead of curses when it is available.

This happens to fix a build error on systems with that library because
when we tried to link ncurses into the binary, we didn't pull tinfo in
as well. =]

It should also provide an easy path for supporting the NetBSD
libterminfo library, but as I don't have access to a NetBSD system I'm
leaving adding that support to those folks.

llvm-svn: 188160

If the tail-callee and caller give the same bits via the same signext/zeroext
attribute then a tail-call should be allowed, since the extension has already
been done by the callee.

llvm-svn: 188159

No functionality change.

llvm-svn: 188158