This allows asm files and Cxx files to be compiled with different flags
rather than treating them identically. LLVM itself has no asm files
other than tests, but this setting is inherited by the compiler-rt
project (unless compiled standalone), which does have asm files.

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

llvm-svn: 243419

This sets the default ASan flags to abort_on_error=1 on OS X. For unit tests and lit tests we set ASAN_OPTIONS back to abort_on_error=0 before running the tests (to avoid crashing). I added two tests that intentionally don't respect the default ASAN_OPTIONS to test the behavior of an empty ASAN_OPTIONS (on OS X we should crash, on Linux we should exit()).

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

llvm-svn: 243418

llvm-svn: 243417

llvm-svn: 243416

Consolidate a bunch of #ifdef _LIBCPP_NO_EXCEPTIONS .. #endif blocks into a single template function. NFC

llvm-svn: 243415

In headers, they might always be pulled in to different TUs, even if
they are declared static or nested in an unnamed namespace.

llvm-svn: 243414

This path add the aarch64 __builtin_thread_pointer support.  It will be
lowered to llvm.aarch64.thread.pointer.

llvm-svn: 243413

This path add the aarch64 lowering of __builtin_thread_pointer.  It uses
the already implemented AArch64ISD::THREAD_POINTER used in TLS generation.

llvm-svn: 243412

llvm-svn: 243411

No functional change intended

--
Reviewers: jdoerfert

Projects: #polly

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

llvm-svn: 243410

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

llvm-svn: 243409

Summary:
I need a test commit for using arc.
This seems like an appropriate commit to use as a test

We may want to port this commit back to 3.7 also

Subscribers: llvm-commits

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

llvm-svn: 243408

http://reviews.llvm.org/D11526

llvm-svn: 243406

no-alias with non-addr-taken globals: they cannot alias a captured
pointer.

If the non-global underlying object would have been a capture were it to
alias the global, we can firmly conclude no-alias. It isn't reasonable
for a transformation to introduce a capture in a way observable by an
alias analysis. Consider, even if it were to temporarily capture one
globals address into another global and then restore the other global
afterward, there would be no way for the load in the alias query to
observe that capture event correctly. If it observes it then the
temporary capturing would have changed the meaning of the program,
making it an invalid transformation. Even instrumentation passes or
a pass which is synthesizing stores to global variables to expose race
conditions in programs could not trigger this unless it queried the
alias analysis infrastructure mid-transform, in which case it seems
reasonable to return results from before the transform started.

See the comments in the change for a more detailed outlining of the
theory here.

This should address the primary performance regression found when the
non-conservatively-correct path of the alias query was disabled.

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

llvm-svn: 243405

Not sure why I wrote what I wrote before.

llvm-svn: 243403

http://reviews.llvm.org/D11526

llvm-svn: 243402

Too many people hope lli would act as an emulator when it's actually
just a tool to help prototype IR code and test the JIT compiler. This
commit makes that fact explicit in the documentation

It also migrates the old style bold/italic doc tags to the preferred
meta tags (.. option::, :program:, etc).

No errors when generating the documents, visual inspection in the HTML
result doesn't show any major difference, apart from the slight style
change.

llvm-svn: 243401

patch by Eugene Zelenko

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

llvm-svn: 243399

Change-Id: I2ebc40f77af75ec6b43ce8364d6d5a1d29988bd6
Phabricator: http://reviews.llvm.org/D11501
llvm-svn: 243398

Summary:
Handle_k was printing an error when killing a process because KillSpawnedProcess was expecting to
be asynchronously notified of the process death, which no longer works, since we don't wait for
the process on a separate thread. However, the whole usage of KillSpawnedProcess is dubious here,
since it tries to be nice and terminate the process first with SIGTERM, which will not have the
intended effect on a ptraced process. I replace this code with a call to
NativeProcessProtocol::Kill, which does not suffer from these problems.

Reviewers: chaoren, ovyalov

Subscribers: lldb-commits

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

llvm-svn: 243397

X86FrameLowering has both a mergeSPUpdates() that accepts a direction, and an
mergeSPUpdatesUp(), which seem to do the same thing, except for a slightly 
different interface. Removed the less general function.
NFC.

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

llvm-svn: 243396

VPAND is a lot faster than VPSHUFB and VPBLENDVB - this patch ensures we attempt to lower to a basic bitmask before lowering to the slower byte shuffle/blend instructions.

Split off from D11518.

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

llvm-svn: 243395

http://reviews.llvm.org/D11526

llvm-svn: 243394

llvm-svn: 243393

llvm-svn: 243392

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

llvm-svn: 243391

Added tests for intrinsics and encoding.

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

llvm-svn: 243390

llvm-svn: 243389

Summary:
The previous way of overriding it was relying on calling "setDefault"
on the global registry, which implies global mutable state.

Reviewers: echristo, atrick

Subscribers: llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243388

rdar://21427916

llvm-svn: 243387

llvm-svn: 243386

out the per-function modref data structures when functions were deleted
or when globals were deleted.

I don't actually know how the global deletion side of this bug hasn't
been hit before, but for the other it just-so-happens that functions
aren't likely to be deleted in the particular part of the LTO pipeline
where we currently enable GMR, so we got lucky.

With this patch, I can self-host with GMR enabled in the normal pass
pipeline!

I was a bit concerned about the compile-time impact of this chang, which
is part of what motivated my prior string of patches to make the
per-function datastructure very dense and fast to walk. With those
changes in place, I can't measure a significant compile time difference
(the difference is around 0.1% which is *way* below the noise) before
and after this patch when building a linked bitcode for all of Clang.

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

llvm-svn: 243385

This fixes the bug https://llvm.org/bugs/show_bug.cgi?id=24152
The float value resides in the first 4 bytes of ValueHandle for both mips and mipsel.

Reviewers: dsanders, samsonov
Subscibers: rsmith, hans, mohit.bhakkad, jaydeep, llvm-commits
Differential: http://reviews.llvm.org/D11448
llvm-svn: 243384

Summary:
Escape characters in strings and strings containing quotes were not appearing correctly in expression values.

Patch from paulmay@microsoft.com

Reviewers: abidh, ChuckR, paulmaybee

Subscribers: greggm, lldb-commits

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

llvm-svn: 243383

Before the patch, the checks were generated internally in
addRuntimeCheck.  Now, we use the new overloaded version of
addRuntimeCheck that takes the ready-made set of checks as a parameter.

The checks are now generated by the client (LoopDistribution) with the
new RuntimePointerChecking::generateChecks API.

Also the new printChecks API is used to print out the checks for
debugging.

This is to continue the transition over to the new model whereby clients
will get the full set of checks from LAA, filter it and then pass it to
LoopVersioning and in turn to addRuntimeCheck.

llvm-svn: 243382

per the coding standard. Thanks Craig Tooper for noticing this.

llvm-svn: 243381

llvm-svn: 243380

Swift has a custom calling convention that also requires some new flags
on arguments and one new attribute on alloca instructions. This patch
does not include the implementation of that calling convention - that
will be provided as part of the open-source release of Swift; this only
reserves the bitcode constant values so that they are not used for
other purposes.

llvm-svn: 243379

llvm-svn: 243378

The linker is now able to link not only LLVM/Clang/LLD for x86 but
even larger programs. I confirmed that it successsfully linked Chrome
for x86. Because the browser is a pretty large program, I think I can
say that the linker is now mostly feature complete. (I'm pretty sure
that there are hidden bugs somewhere, but they shouldn't be significant.)

llvm-svn: 243377