On android std::to_string isn't supported. Replace it with
llvm::utostr.

llvm-svn: 242516

Upon connection termination the waitable handle of an IOObject gets reset to an invalid handle.
This caused a problem since we used the object->GetWaitableHandle as a key to the set of
registered events. The fix is to use something more immutable as a key: we make a copy of the
original waitable handle, instead of holding onto the IOObject.

llvm-svn: 242515

 for extracting target specific information.
-Patches commit r241343: case 'armv7l' was unhandled in
 ARMTargetInfo::getCPUAttr(), and thus it was returning invalid
 characters for macro definition.

Change-Id: I1a0972e5ff5529cd17376c6562047bab8b4da32c
Phabricator: http://reviews.llvm.org/D10839
llvm-svn: 242514

Summary:
This diff is to support Debian packaging,
which sets various hardening-rleated flags
in CFLAGS. They don't make sense for Go,
so we just ignore them.

Reviewers: pcc

Subscribers: llvm-commits, axw

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

llvm-svn: 242513

basic changes to the IR such as folding pointers through PHIs, Selects,
integer casts, store/load pairs, or outlining.

This leaves the feature available behind a flag. This flag's default
could be flipped if necessary, but the real-world performance impact of
this particular feature of GMR may not be sufficiently significant for
many folks to want to run the risk.

Currently, the risk here is somewhat mitigated by half-hearted attempts
to update GlobalsModRef when the rest of the optimizer changes
something. However, I am currently trying to remove that update
mechanism as it makes migrating the AA infrastructure to a form that can
be readily shared between new and old pass managers very challenging.
Without this update mechanism, it is possible that this still unlikely
failure mode will start to trip people, and so I wanted to try to
proactively avoid that.

There is a lengthy discussion on the mailing list about why the core
approach here is flawed, and likely would need to look totally different
to be both reasonably effective and resilient to basic IR changes
occuring. This patch is essentially the first of two which will enact
the result of that discussion. The next patch will remove the current
update mechanism.

Thanks to lots of folks that helped look at this from different angles.
Especial thanks to Michael Zolotukhin for doing some very prelimanary
benchmarking of LTO without GlobalsModRef to get a rough idea of the
impact we could be facing here. So far, it looks very small, but there
are some concerns lingering from other benchmarking. The default here
may get flipped if performance results end up pointing at this as a more
significant issue.

Also thanks to Pete and Gerolf for reviewing!

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

llvm-svn: 242512

In particular, it's much easier to read, as it doesn't expand all
the way on wide-screen displays.

CSS committed under LLVM license with explicit permission from
Daniel Bünzli <daniel.buenzli@erratique.ch>.

llvm-svn: 242511

Since r230724 ("Skip promotable allocas to improve performance at -O0"), there is a regression in the generated debug info for those non-instrumented variables. When inspecting such a variable's value in LLDB, you often get garbage instead of the actual value. ASan instrumentation is inserted before the creation of the non-instrumented alloca. The only allocas that are considered standard stack variables are the ones declared in the first basic-block, but the initial instrumentation setup in the function breaks that invariant.

This patch makes sure uninstrumented allocas stay in the first BB.

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

llvm-svn: 242510

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

llvm-svn: 242509

We shouldn't crash despite the AMD64 ABI not giving clear guidance as to
how to pass around vector types <= 32 bits.  Instead, classify such
vectors as INTEGER to be compatible with GCC.

This fixes PR24162.

llvm-svn: 242508

In response to Richard Smith's comment (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150622/131782.html), this patch disables "redefine_extname" pragma for C++ code. Also, I added a test that this pragma doesn't apply to static declarations.
Differential Revision: http://reviews.llvm.org/D10805

llvm-svn: 242507

llvm-svn: 242506

llvm-svn: 242505

Guessing which file name to replace based on the -main-file-name
argument to -cc1 is flawed. Instead, keep track of which arguments are
inputs to each command.

llvm-svn: 242504

Helps explain some of the background behind this bit of code.

llvm-svn: 242503

llvm-svn: 242501

This is mostly done to disable the PostRAScheduler which optimizes for
instruction latencies which isn't a good fit for out-of-order
architectures. This also allows to leave out the itinerary table in
swift in favor of the SchedModel ones.

This change leads to performance improvements/regressions by as much as
10% in some benchmarks, in fact we loose 0.4% performance over the
llvm-testsuite for reasons that appear to be unknown or out of the
compilers control. rdar://20803802 documents the investigation of
these effects.

While it is probably a good idea to perform the same switch for the
other ARM out-of-order CPUs, I limited this change to swift as I cannot
perform the benchmark verification on the other CPUs.

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

llvm-svn: 242500

- introduces a new cc1 option -fmodule-format=[raw,obj]
  with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
  a PCHContainerReader.

Thanks to Richard Smith for reviewing this patch!

llvm-svn: 242499

This was increasing the instruction count if the fadd has multiple uses.

llvm-svn: 242498

llvm-svn: 242496

llvm-svn: 242493

llvm-svn: 242492

llvm-svn: 242491

llvm-svn: 242490

The problems in the llvm target got fixed in r242481 and r242482.

Related to rdar://20544153, rdar://20660786

llvm-svn: 242489

llvm-svn: 242488

Reviewers: Duncan P. N. Exon Smith
llvm-svn: 242487

Those new constructors make it more natural to construct an object for a function. For example, previously to build a LoopInfo for a function, we need four statements:

DominatorTree DT;
LoopInfo LI;
DT.recalculate(F);
LI.analyze(DT);

Now we only need one statement:

LoopInfo LI(DominatorTree(F));

http://reviews.llvm.org/D11274

llvm-svn: 242486

Summary: This corresponds to the change made in r237417 - "Doxygen: Enable autobrief feature and update coding standards."

Reviewers: eliben

Subscribers: eliben, cfe-commits

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

llvm-svn: 242485

Before:
  - (void)shortf:(GTMFoo *)theFoo
  dontAlignNamef:(NSRect)theRect {
  }

After:
  - (void)shortf:(GTMFoo *)theFoo
      dontAlignNamef:(NSRect)theRect {
  }

Patch by Kwasi Mensah, thank you!

llvm-svn: 242484

This (hopefully) brings more clarity. No functional changes (intended).

llvm-svn: 242483

Constructing a name based on the function name didn't give us a unique
symbol if we had more than one setjmp in a function. Using
MCContext::createTempSymbol() always gives us a unique name.

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

llvm-svn: 242482

llvm.eh.sjlj.setjmp was used as part of the SjLj exception handling
style but is also used in clang to implement __builtin_setjmp.  The ARM
backend needs to output additional dispatch tables for the SjLj
exception handling style, these tables however can't be emitted if
llvm.eh.sjlj.setjmp is simply used for __builtin_setjmp and no actual
landing pad blocks exist.

To solve this issue a new llvm.eh.sjlj.setup_dispatch intrinsic is
introduced which is used instead of llvm.eh.sjlj.setjmp in the SjLj
exception handling lowering, so we can differentiate between the case
where we actually need to setup a dispatch table and the case where we
just need the __builtin_setjmp semantic.

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

llvm-svn: 242481

This goes with r218884 from, um, last autumn.

rdar://problem/21754114

llvm-svn: 242480

llvm-svn: 242457

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

Include what we use, instead of letting them get pulled in implictly. This makes the tests work on VS. Thanks to STL for the report

llvm-svn: 242454

An internal builder was failing.

llvm-svn: 242452

Makes the comments for proveNoWrapByVaryingStart consistent with the
rest of ScalarEvolution.h

llvm-svn: 242451

llvm-svn: 242450

llvm-svn: 242449