constants, as discovered by ASAN.

Patch by Mehdi Amini!

llvm-svn: 221401

that we load debug information properly.  If we don't
explicitly add-dsym, sometimes Spotlight will help out
and tell us about the dSYM but we shouldn't be relying
on that.  Thanks to Jim for catching this.

<rdar://problem/16424661>

llvm-svn: 221400

Add a setting escape-non-printables that drives whether the StringPrinter should or should not escape sequences such as \t, \n, .. and generally any non-printing character

The recent StringPrinter changes made this behavior the default, and the setting defaults to yes
If you want to change this behavior and see non-printables unescaped (e.g. "a\tb" as "a    b"), set it to false

Fixes rdar://12969594

llvm-svn: 221399

llvm-svn: 221398

The st_other field can contains not only visibility flag so we should
retrieve a visibility flag using a bit-mask.

llvm-svn: 221397

Both of the intrinsics get autoupgraded to target independent
intrinsics.

llvm-svn: 221396

llvm-svn: 221395

This patch moves the SCEV based (re)generation of values before the checking for
scop-constant terms. It enables us to provide SCEV based replacements, which
are necessary to correctly generate OpenMP subfunctions when using the SCEV
based code generation.

When recomputing a new value for a value used in the code of the original scop,
we previously directly returned the same original value for all scop-constant
expressions without even trying to regenerate these values using our SCEV
expression. This is correct when the newly generated code remains fully in the
same function, however in case we want to outline parts of the newly generated
scop into subfunctions, this approach means we do not have any opportunity to
update these values in the SCEV based code generation. (In the non-SCEV based
code generation, we can provide such updates through the GlobalMap). To ensure
we have this opportunity, we first try to regenerate scalar terms with our SCEV
builder and will only return scop-constant expressions if SCEV based code
generation was not possible.

This change should not affect the results of the existing code generation
passes. It only impacts the upcoming OpenMP based code generation.

This commit also adds a test case. This test case passes before and after this
commit. It was added to ensure test coverage for the changed code.

llvm-svn: 221393

This new `getVisibility()` function will also be used in the LLD code.

llvm-svn: 221392

Custom targets in cmake cannot be exported, and this dependency is only
needed in the combined build to ensure that Intrinsics.gen is created
before compiling CodeGen. In the standalone, all of LLVM is build first.

llvm-svn: 221391

llvm-svn: 221389

There was no good reason why this code was split accross two functions.

In subsequent changes we will change the order in which values are looked up.
Doing so would make the split into two functions even more arbitrary.

We also slightly improve the documentation.

llvm-svn: 221388

llvm-svn: 221387

Summary:
X86FastISel::fastMaterializeAlloca was incorrectly conditioning its
opcode selection on subtarget bitness rather than pointer size.

Differential Revision: http://reviews.llvm.org/D6136

llvm-svn: 221386

When we are generating the global initializer functions, we call
CGDebugInfo::EmitFunctionStart() with a valid decl which is describing
the initialized global variable. Do not update the DeclCache with this
key as it will overwrite the the cached variable DIGlobalVariable with
the newly created artificial DISubprogram.

One could wonder if we should put artificial subprograms in the DIE tree
at all (there are vaild uses for them carrying line information though).

llvm-svn: 221385

llvm-svn: 221384

llvm-svn: 221383

llvm-svn: 221382

The current ASan testcase Posix/allow_user_segv.cc expects SIGBUS to be triggered on 32-bit Darwin. This has apparently changed on 10.10 to trigger SIGSEGV instead, just as on 64-bit. Let's just install handlers for both SIGSEGV and SIGBUS instead of #ifdef'ing.

Reviewed at http://reviews.llvm.org/D6121

llvm-svn: 221381

Fixes a failing ASan testcase (TestCases/stack-use-after-return.cc) on OS X 10.10.

Reviewed at http://reviews.llvm.org/D6120

llvm-svn: 221380

This also fixes the test/asan/TestCases/Darwin/malloc_zone-protected.cc test failure on OS X 10.10.

Reviewed at http://reviews.llvm.org/D6119

llvm-svn: 221379

llvm-svn: 221378

This works around the limitation that PTX does not allow .param space
loads/stores with arbitrary pointers.

If a function has a by-val struct ptr arg, say foo(%struct.x *byval %d), then
add the following instructions to the first basic block :

%temp = alloca %struct.x, align 8
%tt1 = bitcast %struct.x * %d to i8 *
%tt2 = llvm.nvvm.cvt.gen.to.param %tt2
%tempd = bitcast i8 addrspace(101) * to %struct.x addrspace(101) *
%tv = load %struct.x addrspace(101) * %tempd
store %struct.x %tv, %struct.x * %temp, align 8

The above code allocates some space in the stack and copies the incoming
struct from param space to local space. Then replace all occurences of %d
by %temp.

Fixes PR21465.

llvm-svn: 221377

llvm-svn: 221376

Change `NamedMDNode::getOperator()` from returning `MDNode *` to
returning `Value *`.  To reduce boilerplate at some call sites, add a
`getOperatorAsMDNode()` for named metadata that's expected to only
return `MDNode` -- for now, that's everything, but debug node named
metadata (such as llvm.dbg.cu and llvm.dbg.sp) will soon change.  This
is part of PR21433.

Note that there's a follow-up patch to clang for the API change.

llvm-svn: 221375

llvm-svn: 221374

Change `SlotTracker::CreateMetadataSlot()` and
`SlotTracker::getMetadataSlot()` to use `Value` instead of `MDNode`.
Part of PR21433.

llvm-svn: 221373

Dead code identified by the Clang static analyzer.

llvm-svn: 221372

llvm-svn: 221371

llvm-svn: 221370

llvm-svn: 221369

Found by the Clang static analyzer.

llvm-svn: 221368

llvm-svn: 221367

Found by the Clang static analyzer.

llvm-svn: 221366

This reverts commit eefd2eaad43c5c2b17953ae7ed1e72b28e696f7b.

Apparently, this change was a bit premature.

llvm-svn: 221365

uninstrumented vararg functions.

llvm-svn: 221364

llvm-svn: 221363

This incorporates some of the newer functions used by (e.g.) the Go runtime.

llvm-svn: 221362

ABI list.

llvm-svn: 221361

We currently have no infrastructure to support these correctly.

This is accomplished by generating a call to a runtime library function that
aborts at runtime in place of the regular wrapper for such functions. Direct
calls are rewritten in the usual way during traversal of the caller's IR.

We also remove the "split-stack" attribute from such wrappers, as the code
generator cannot currently handle split-stack vararg functions.

llvm-svn: 221360