This goes with r186925, which reverted Pavel's commit in r186498.

Also, add a correctness test for the future.

llvm-svn: 187133

PR16690

llvm-svn: 187132

Live debugging for threaded inferiors is not yet implemented on FreeBSD

llvm-svn: 187131

llvm-svn: 187130

-dead_strip isn't supported by FreeBSD's ld.

llvm-svn: 187129

Better to have tests run even on non-AArch64 platforms.

llvm-svn: 187128

PR title updated to indicate that FreeBSD is also affected: Backtrace
command does not display c++ member function names on Linux or FreeBSD

llvm-svn: 187127

The last patch corrected some issues, but constant-pool entries had actual
codegen bugs in the large memory model (which MCJIT uses).

llvm-svn: 187126

- Modifies the DWARF parser for DWARF 4 specification of hi_pc as an offset-from-low-pc.

llvm-svn: 187125

llvm-svn: 187124

This only makes a difference with broken versions of env (like the one in
gnutools32) that always return 0.

llvm-svn: 187123

The reason this clang invocation was failing is that it had two %s. We would
close stdout after the first one and report a fatal error when trying to
print the second.

llvm-svn: 187122

The tests use a plugin based on the name from sys.platform.
Unfortunately that string includes the major version number in
Python 2.7, so the tests would look for builder_freebsd9.py,
builder_freebsd10.py, etc.

The issue doesn't affect Linux as Python returns 'linux2' also
on Linux 3.x -- see http://bugs.python.org/issue12326 for details.

It seems later versions of Python will drop the major version
number, so adopt this convention now for FreeBSD.

llvm-svn: 187121

This should actually make the MCJIT tests pass again on AArch64. I don't know
how I missed their failure before.

llvm-svn: 187120

Fix a bug in TableGen where the intrinsic function name recognizer could mis-identify names if one was a prefix substring of the other

For two intrinsics 'llvm.nvvm.texsurf.handle' and 'llvm.nvvm.texsurf.handle.internal',
TableGen was emitting matching code like:

  if (Name.startswith("llvm.nvvm.texsurf.handle")) ...
  if (Name.startswith("llvm.nvvm.texsurf.handle.internal")) ...

We can never match "llvm.nvvm.texsurf.handle.internal" here because it will
always be erroneously matched by the first condition.

The fix is to sort the intrinsic names and emit them in reverse order.

llvm-svn: 187119

Before:
  #define OPERATION_CASE(name) \
    case OP_name:              \
    return operations::Operation##name

  switch (OpCode) {
      CASE(Add);
      CASE(Subtract);
    default:
      return operations::Unknown;
  }

After:
  #define OPERATION_CASE(name) \
    case OP_name:              \
      return operations::Operation##name;

  switch (OpCode) {
    CASE(Add);
    CASE(Subtract);
    default:
      return operations::Unknown;
  }

llvm-svn: 187118

llvm-svn: 187117

Before the patch we took advantage of the fact that the compare and
branch are glued together in the selection DAG and fused them together
(where possible) while emitting them.  This seemed to work well in practice.
However, fusing the compare so early makes it harder to remove redundant
compares in cases where CC already has a suitable value.  This patch
therefore uses the peephole analyzeCompare/optimizeCompareInstr pair of
functions instead.

No behavioral change intended, but it paves the way for a later patch.

llvm-svn: 187116

In TUs with large classes, a matcher like

  methodDecl(ofClass(recordDecl(has(varDecl()))))

(finding all member functions of classes with static variables)
becomes unbearably slow otherwise.

llvm-svn: 187115

Split the old getNewValue into two parts:

1. The function "lookupAvailableValue" that return the new version of
the instruction which is already available.

2. The function calls "lookupAvailableValue", and tries to generate
the new version if it is not available yet.

llvm-svn: 187114

llvm-svn: 187113

As with the stores, these instructions can trap when the condition is false,
so they are only used for things like (cond ? x : *ptr).

llvm-svn: 187112

These instructions are allowed to trap even if the condition is false,
so for now they are only used for "*ptr = (cond ? x : *ptr)"-style
constructs.

llvm-svn: 187111

Consider which set is being increased or decreased before comparing.

llvm-svn: 187110

llvm-svn: 187109

This lets heuristics easily pick the most important set to follow.

llvm-svn: 187108

llvm-svn: 187107

Make sure the context and type fields are MDNodes. We will generate
verification errors if those fields are non-empty strings.
Fix testing cases to make them pass the verifier.

llvm-svn: 187106

llvm-svn: 187104

The language reference says that:

"If a symbol appears in the @llvm.used list, then the compiler,
assembler, and linker are required to treat the symbol as if there is
a reference to the symbol that it cannot see"

Since even the linker cannot see the reference, we must assume that
the reference can be using the symbol table. For example, a user can add
__attribute__((used)) to a debug helper function like dump and use it from
a debugger.

llvm-svn: 187103

String operations resulted by raw_string_ostream in the INVALID macro can lead
to significant compile-time overhead when compiling large size source code.
This is because raw_string_ostream relies on TypeFinder class, whose
compile-time cost increases as the size of the module increases. This patch
targets to ensure that it only track detection failures if actually needed.
In this way, we can avoid expensive string operations in normal execution.

With this patch file, the relative compile-time cost of Polly-detect pass does
not increase even when compiling very large size source code.

Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 187102

llvm-svn: 187101

llvm-svn: 187100

llvm-svn: 187099

Thanks to Nick Lewycky for noticing it.

llvm-svn: 187098

BalancedDelimiterTracker::diagnoseOverflow calls P.SkipUntil, and before this
patch P.SkipUnti is recursive, causing problems on systems with small stacks.
This patch fixes it by making P.SkipUnti non recursive when just looking for
eof.

llvm-svn: 187097

llvm-svn: 187096

llvm-svn: 187095

Handle the case where we are stepping through code with no symbols, so we can't really find the function start PC 
and so the StackID changes with every step.  Do so by checking the parent frame ID, and if it hasn't changed,
then we haven't stepped in.

rdar://problem/14516227

llvm-svn: 187094

There's no need to specify a flag to omit frame pointer elimination on non-leaf
nodes...(Honestly, I can't parse that option out.) Use the function attribute
stuff instead.

llvm-svn: 187093