A PHI on a catchpad might be used by both edges out of the catchpad,
feeding back into a loop.  In this case, just use the insertion point.
Anything more clever would require new basic blocks or PHI placement.

llvm-svn: 251442

1. Make the warning more strict in C mode. r172696 added code to suppress
   warnings from macro expansions in system headers, which checks
   `SourceMgr.isMacroBodyExpansion(E->IgnoreParens()->getExprLoc())`. Consider
   this snippet:

   #define FOO(x) (x)
   void f(int a) {
     FOO(a);
   }

   In C, the line `FOO(a)` is an `ImplicitCastExpr(ParenExpr(DeclRefExpr))`,
   while it's just a `ParenExpr(DeclRefExpr)` in C++. So in C++,
   `E->IgnoreParens()` returns the `DeclRefExpr` and the check tests the
   SourceLoc of `a`. In C, the `ImplicitCastExpr` has the effect of checking the
   SourceLoc of `FOO`, which is a macro body expansion, which causes the
   diagnostic to be skipped. It looks unintentional that clang does different
   things for C and C++ here, so use `IgnoreParenImpCasts` instead of
   `IgnoreParens` here. This has the effect of the warning firing more often
   than previously in C code – it now fires as often as it fires in C++ code.

2. Suppress the warning if it would warn on `UNREFERENCED_PARAMETER`.
   `UNREFERENCED_PARAMETER` is a commonly used macro on Windows and it happens
   to uselessly trigger -Wunused-value. As discussed in the thread
   "rfc: winnt.h's UNREFERENCED_PARAMETER() vs clang's -Wunused-value" on
   cfe-dev, fix this by special-casing this specific macro. (This costs a string
   comparison and some fast-path lexing per warning, but the warning is emitted
   rarely. It fires once in Windows.h itself, so this code runs at least once
   per TU including Windows.h, but it doesn't run hundreds of times.)

http://reviews.llvm.org/D13969

llvm-svn: 251441

llvm-svn: 251440

Summary: Similar to http://reviews.llvm.org/rL242319, which was for ARM.

Reviewers: chying, ovyalov

Subscribers: aemerson, tberghammer, danalbert, srhines, lldb-commits

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

llvm-svn: 251439

This recommits r250719, which caused a failure in SPEC2000.gcc
because of the incorrect insert point for the new wider load.

Convert two halfword loads into a single 32-bit word load with bitfield extract
instructions. For example :
  ldrh w0, [x2]
  ldrh w1, [x2, #2]
becomes
  ldr w0, [x2]
  ubfx w1, w0, #16, #16
  and  w0, w0, #ffff

llvm-svn: 251438

llvm-svn: 251437

It causes miscompilation of llvm/lib/ExecutionEngine/Interpreter/Execution.cpp.
See also PR25324.

llvm-svn: 251436

llvm-svn: 251434

llvm-svn: 251432

Summary: This is a follow on to post review comments on revision r248276.

Patch by Scott Egerton.

Reviewers: vkalintiris, dsanders

Subscribers: joerg, rengolin, cfe-commits

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

llvm-svn: 251430

Create a new interface addSuccessorWithoutWeight(MBB*) in MBB to add successors when optimization is disabled.

When optimization is disabled, edge weights that are stored in MBB won't be used so that we don't have to store them. Currently, this is done by adding successors with default weight 0, and if all successors have default weights, the weight list will be empty. But that the weight list is empty doesn't mean disabled optimization (as is stated several times in MachineBasicBlock.cpp): it may also mean all successors just have default weights.

We should discourage using default weights when adding successors, because it is very easy for users to forget update the correct edge weights instead of using default ones (one exception is that the MBB only has one successor). In order to detect such usages, it is better to differentiate using default weights from the case when optimizations is disabled.

In this patch, a new interface addSuccessorWithoutWeight(MBB*) is created for when optimization is disabled. In this case, MBB will try to maintain an empty weight list, but it cannot guarantee this as for many uses of addSuccessor() whether optimization is disabled or not is not checked. But it can guarantee that if optimization is enabled, then the weight list always has the same size of the successor list.

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

llvm-svn: 251429

Summary:
This change could be way off-piste, I'm looking for any feedback on whether it's an acceptable approach.

It never seems to be a problem to gobble up as many reduction values as can be found, and then to attempt to reduce the resulting tree. Some of the workloads I'm looking at have been aggressively unrolled by hand, and by selecting reduction widths that are not constrained by a vector register size, it becomes possible to profitably vectorize. My test case shows such an unrolling which SLP was not vectorizing (on neither ARM nor X86) before this patch, but with it does vectorize.

I measure no significant compile time impact of this change when combined with D13949 and D14063. There are also no significant performance regressions on ARM/AArch64 in SPEC or LNT.

The more principled approach I thought of was to generate several candidate tree's and use the cost model to pick the cheapest one. That seemed like quite a big design change (the algorithms seem very much one-shot), and would likely be a costly thing for compile time. This seemed to do the job at very little cost, but I'm worried I've misunderstood something!

Reviewers: nadav, jmolloy

Subscribers: mssimpso, llvm-commits, aemerson

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

llvm-svn: 251428

Linking options for particular file depend on the option that specifies the file.
Currently there are two:

* -mlink-bitcode-file links in complete content of the specified file.
* -mlink-cuda-bitcode links in only the symbols needed by current TU.
   Linked symbols are internalized. This bitcode linking mode is used to
   link device-specific bitcode provided by CUDA.

Files are linked in order they are specified on command line.

-mlink-cuda-bitcode replaces -fcuda-uses-libdevice flag.

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

llvm-svn: 251427

This file uses things like fprintf and stderr and <cstdio> is the right
header to include. I was getting build errors without it.

llvm-svn: 251426

Summary:
Currently, when the SLP vectorizer considers whether a phi is part of a reduction, it dismisses phi's whose incoming blocks are not the same as the block containing the phi. For the patterns I'm looking at, extending this rule to allow phis whose incoming block is a containing loop latch allows me to vectorize certain workloads.

There is no significant compile-time impact, and combined with D13949, no performance improvement measured in ARM/AArch64 in any of SPEC2000, SPEC2006 or LNT.

Reviewers: jmolloy, mcrosier, nadav

Subscribers: mssimpso, nadav, aemerson, llvm-commits

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

llvm-svn: 251425

Summary:
Certain workloads, in particular sum-of-absdiff loops, can be vectorized using SLP if it can treat select instructions as reduction values.

The test case is a bit awkward. The AArch64 cost model needs some tuning to not be so pessimistic about selects. I've had to tweak the SLP threshold here.

Reviewers: jmolloy, mzolotukhin, spatel, nadav

Subscribers: nadav, mssimpso, aemerson, llvm-commits

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

llvm-svn: 251424

llvm-svn: 251423

http://reviews.llvm.org/D14101

llvm-svn: 251422

Since 219143, this file is missing from Makefile build. Committed as
obvious.

llvm-svn: 251421

When emitting a remark for a conditional branch annotation, the remark
uses the line location information of the conditional branch in the
message.  In some cases, that information is unavailable and the
optimization would segfaul. I'm still not sure whether this is a bug or
WAI, but the optimizer should not die because of this.

llvm-svn: 251420

llvm-svn: 251419

The existing behavior was correct on Darwin, which is probably the
platform it was written for.

Before this change, we would rewrite "align 8" to ".align 3" and then
fail to make it through the integrated assembler because 3 is not a
power of 2.

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

llvm-svn: 251418

Add Socket::Create factory method which uses socket protocol to find an appropriate implementation class.

http://reviews.llvm.org/D14085

llvm-svn: 251417

Fix Clang-tidy modernize-use-nullptr warnings in include/lldb/DataFormatters, Breakpoint and Utility; other minor fixes.

llvm-svn: 251416

Microsoft connect bug: https://connect.microsoft.com/VisualStudio/feedback/details/1741530

llvm-svn: 251415

`qsort` as a file-scope local function name was confusing.

llvm-svn: 251414

For CloudABI's toolchain I have a symlink that goes from <target>-ar and
<target>-ranlib to LLVM's ar binary, to mimick GNU Binutils' naming
scheme. The problem is that if we're targetting ARM64, the name of the
ranlib executable is aarch64-unknown-cloudabi-ranlib. This already
contains the string "ar".

Let's move the "ranlib" test above the "ar" test. It's not that likely
that we're going to see operating systems or harwdare architectures that
are called "ranlib".

Reviewed by:	rafael
Differential Revision:	http://reviews.llvm.org/D14123

llvm-svn: 251413

llvm-svn: 251412

[CMake] Get rid of LLVM_DYLIB_EXPORT_ALL, and make it the default, add libLLVM-C on darwin to cover the C API needs.

Summary:
We've had a lot of discussion in the past about the meaningful and useful default behaviors for the llvm-shlib tool. The original implementation was heavily geared toward Apple's use, and I think that was wrong. This patch seeks to correct that.

I've removed the LLVM_DYLIB_EXPORT_ALL variable and made libLLVM export everything by default.

I've also added a new target that is only built on Darwin for libLLVM-C as a library that re-exports the LLVM-C API. This library is not built on Linux because ELF doesn't support re-export libraries in the same way MachO does.

Reviewers: chapuni, resistor, bogner, axw

Subscribers: llvm-commits

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

llvm-svn: 251411

Expose isMutable via libClang and python bindings.

Patch by Jonathan B Coe!

llvm-svn: 251410

convert float to half with mask/maskz for the reg to reg version and mask for the reg to mem version (there is no maskz version for reg to mem).

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

llvm-svn: 251409

This matches ld.bfd and ld.gold behavior. The change is simple enough
and avoid trouble to consumers (they don't have to change their Makefiles).
Side note: found while trying to build FreeBSD base system with lld.

llvm-svn: 251408

llvm-svn: 251407

Specifically, don't wrap between the {} of an empty constructor if the
"}" falls on column 81 and ConstructorInitializerAllOnOneLineOrOnePerLine
is set.

llvm-svn: 251406

Summary:
If this option is set, clang-format will always insert a line wrap, e.g.
before the first parameter of a function call unless all parameters fit
on the same line. This obviates the need to make a decision on the
alignment itself.

Use this style for Google's JavaScript style and add some minor tweaks
to correctly handle nested blocks etc. with it. Don't use this option
for for/while loops.

Reviewers: klimek

Subscribers: klimek, cfe-commits

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

llvm-svn: 251405

llvm-svn: 251404

llvm-svn: 251403

* Remove an unneccessary re-computaion on arch spec from the ELF file
* Use a local cache to optimize name based section lookups in symtab
  parsing
* Optimize C++ method basename validation with replacing a regex with
  hand written code

These modifications reduce the time required to parse the symtab from
large applications by ~25% (tested with LLDB as inferior)

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

llvm-svn: 251402

Summary: After D13851 landed, we saw backend crashes when compiling the reduced test case included in this patch. The right fix seems to be to allow these vector types for expansion in instruction selection.

Reviewers: rengolin, t.p.northover

Subscribers: RKSimon, t.p.northover, aemerson, llvm-commits, rengolin

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

llvm-svn: 251401

Summary:
This change deprecates -m/+m dotest options (the options are still recognized but they print an
error message pointing to the new options) and adds a new lldb-mi test category instead. To just
run lldb-mi tests, use '-G lldb-mi'. To skip lldb-mi tests, use '--skip-category lldb-mi'. All
lldb-mi tests are marked as such using the getCategories method on the base MiTestCaseBase class
and the @lldbmi_test decorator is not needed. In case one still needs to annotate a specific test
function as an lldb-mi test, one can use the @add_test_categories(['lldb-mi']) decorator to
achieve that.

Reviewers: tfiala, dawn, ki.stfu, abidh

Subscribers: lldb-commits

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

llvm-svn: 251400