We avoided computing DAG height/depth during Node printing because it
shouldn't depend on an otherwise valid DAG. But this has become far
too annoying for the common case of a valid DAG where we want to see
valid values. If doing the computation on-the-fly turns out to be a
problem in practice, then I'll add a mode to the diagnostics to only
force it when we're likely to have a valid DAG, otherwise explicitly
print INVALID instead of bogus numbers. For now, just go for it all
the time.

llvm-svn: 176314

This class tracks dependence between memory instructions using underlying
objects of memory operands. 

llvm-svn: 176313

these two new files.

llvm-svn: 176312

llvm-svn: 176311

This seems to be what ld does, but I'm not sure how it works with symbol interposition.

With this hello-world with glibc dynamically linked works.

llvm-svn: 176310

llvm-svn: 176309

// rdar://13158394

llvm-svn: 176308

- if you have LLDB checked out in $llvm/tools, CMake will build it now!
- LLDB is known to build on Linux with libstdc++ and GCC 4.6/4.7 or Clang 3.3
- to run lldb tests, do "make check-lldb" after a build

llvm-svn: 176307

- add missing scripts (driver, tests, etc...)
- enable running of tests from cmake with "make check-lldb" target
- fix up problem with clang dependencies (this enables parallel builds)
- implement platform-specific FIXMEs in source/CMakeLists.txt

llvm-svn: 176306

SelectionDAGIsel::LowerArguments needs a function, not a basic block. So it
makes sense to pass it the function instead of extracting a basic-block from
the function and then tossing it. This is also more self-documenting (functions
have arguments, BBs don't).

In addition, added comments to a couple of Select* methods.

llvm-svn: 176305

These can be easily queried by the back-end.

llvm-svn: 176304

use of stand-alone protocol as type and uses
id<proto>. Modify warning to say what compiler 
is doing. // rdar//13158394

llvm-svn: 176303

llvm-svn: 176302

This was causing the folding set to fail to fold attributes, because it was
being calculated in one spot without an empty values string but here with an
empty values string.

llvm-svn: 176301

The instcombine recognized pattern looks like:
a = b * c
d = a +/- Cst
or
a = b * c
d = Cst +/- a

When creating the new operands for fadd or fsub instruction following the related fmul, the first operand was created with the second original operand (M0 was created with C1) and the second with the first (M1 with Opnd0).

The fix consists in creating the new operands with the appropriate original operand, i.e., M0 with Opnd0 and M1 with C1.

llvm-svn: 176300

llvm-svn: 176298

our bitwise compare is equal to the field we're looking for.

Noticed on inspection.

llvm-svn: 176296

Some buildbots use a shell that doesn't know 'exit'. So instead of using XFAIL
for UseAuto/iterator.cpp (since this problem doesn't exist for cmake) leave the
'grep' command and turn off the others.

llvm-svn: 176295

llvm-svn: 176294

    
The way 'make check-all' causes configuration files to be generated results in
the cpp11-migrate/Makefile not being triggered to generated any files. These
files are necessary for UseAuto/iterator.cpp to run. Turning off this test
until the problem is fixed properly.

llvm-svn: 176293

llvm-svn: 176292

at a time.  Enforce this for now (we should relax the requirement when we have a little more time.)

<rdar://problem/13314462>

llvm-svn: 176291

llvm-svn: 176289

llvm-svn: 176288

We make the cost for calling libm functions extremely high as emitting the
calls is expensive and causes spills (on x86) so performance suffers. We still
vectorize important calls like ceilf and friends on SSE4.1. and fabs.

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

llvm-svn: 176287

calls and declarations.

LLVM has a default CC determined by the target triple.  This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention.  Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect.  However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility.  Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile;  so it's quite
important to get this right.

Defining runtime functions locally is quite common in embedded
applications.

llvm-svn: 176286

llvm-svn: 176285

llvm-svn: 176283

Fix the getCompilerVersion() function to do the right thing with clang 5.0 which now says "LLVM version" instead of "clang version".

llvm-svn: 176282

llvm-svn: 176281

llvm-svn: 176280

llvm-svn: 176279

llvm-svn: 176278

llvm-svn: 176277

llvm-svn: 176276

llvm-svn: 176275

Also removed the use of llvm::raw_string_ostream as it wasn't needed. 

Also fixed a crasher that could occur when the following line returned a C string tied to a local variable:

    return OS.str().c_str();

I am guessing "static std::string buf;" was supposed to get assigned to "OS.str()" and then have "buf.c_str()" returned. 

Modified the non-apple version code to cache its value and not recompute the version every time.

llvm-svn: 176274

other per-instruction statistics.

llvm-svn: 176273

llvm-svn: 176272

have their own code completion comments. Use those in 
their properties in this case. 
// rdar://12791315

llvm-svn: 176271