No functional change, but it preps codegen for the future when SABSDIFF
will start getting generated in anger.

llvm-svn: 242545

llvm-svn: 242543

Follow-up on discussion in http://reviews.llvm.org/D11220

llvm-svn: 242542

llvm-svn: 242541

llvm-svn: 242540

The is so that we can avoid using libgcc and use compiler-rt with
mingw-w64.

Related driver patch
http://reviews.llvm.org/D11077

I have tested this with mingw-w64 and everything seems to be in order.
I also sent this patch to the mingw-w64 mailing list for them to look at.

Patch by Martell Malone.

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

llvm-svn: 242539

For open_memstream() files, buffer pointer is only valid immediately after
fflush() or fclose(). Fix the fclose() interceptor to unpoison after the
REAL(fclose) call, not before it.

llvm-svn: 242535

Individual matchers might not be convertible to each other's kind, but
they might still all be convertible to the target kind.
All the callers already know the target kind, so just pass it down.

llvm-svn: 242534

I will send an entry in docs/CommandGuide for review today.

llvm-svn: 242533

patch by Eugene Zelenko.

llvm-svn: 242529

- Changed the default FPU of cortex-m4.
- Removed "cortex-m4f" entry. Currently not supported.

Change-Id: I73121e358aa9e7ba68eb001c2143df390ff2352a
Phabricator: http://reviews.llvm.org/D11100
llvm-svn: 242528

Patch by Eugene Zelenko.

llvm-svn: 242525

Only pointer values in constant address space are assumed to be strings. For
all other pointers their address is printed.

llvm-svn: 242524

llvm-svn: 242523

Change default CPU for MIPS64 Android. Now it is mips64r6.

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

llvm-svn: 242522

llvm-svn: 242521

This is mainly for the benefit of GlobalMerge, so that an alias into a
MergedGlobals variable has the same size as the original non-merged
variable.

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

llvm-svn: 242520

Don't chane the CFI information when a conditional instruction
is emulated (eg.: popeq {r0, pc}) because the CFI for the next
instruction should be the same as the CFI for the current instruction.

Differential revision: http://reviews.llvm.org/D11258

llvm-svn: 242519

Summary:
Adds '--svn-path BRANCH' that causes the script to export the specified path
from each project. Otherwise the tag specified by -release, -rc, etc. will be
used. The version portion of the package name will be 'test-$path' (any forward
slashes in the branch name are replaced with underscores), for example:
  -svn-path trunk => clang+llvm-test-trunk-mips-linux-gnu.tar.xz
  -svn-path branches/release_35 => clang+llvm-test-branches_release_35-mips-linux-gnu.tar.xz

This is primarily useful for bringing new release packages up to standard
without needing to create and maintain a tag for the purpose.

Reviewers: tstellarAMD, hans

Subscribers: llvm-commits

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

llvm-svn: 242518

Summary:
It seems that reading of register data is the biggest bottleneck in LLGS at the moment. Sending
four registers instead of the full GPR set increases the jThreadsInfo processing time about
6-fold. Until we figure out where is this time going, this commit limits the amount of data we
send to provide a more fluid debugging experience.

Reviewers: tberghammer, ovyalov

Subscribers: lldb-commits

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

llvm-svn: 242517

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