InstSimplify doesn't always know how to fold a bitcast of a constant vector.
In particular, the logic in InstSimplify doesn't know how to handle the case
where the constant vector in input contains some undef elements, and the
number of elements is smaller than the number of elements of the bitcast
vector type.

llvm-svn: 281332

llvm-svn: 281331

llvm-svn: 281330

llvm-svn: 281329

llvm-svn: 281328

This reverts commit r281314. Speculatively revert as it's possible this caused linker errors: http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/19656

llvm-svn: 281327

My previous commit should of removed a test file but I missed it.

llvm-svn: 281326

llvm-svn: 281325

Before, only Thumb functions were marked as ".code 16". These
".code x" directives are effective until the next directive of its
kind is encountered. Therefore, in code with interleaved ARM and
Thumb functions, it was possible to declare a function as ARM and
end up with a Thumb function after assembly. A test has been added.

An existing test has also been fixed to take this change into
account.

Reviewers: aschwaighofer, t.p.northover, jmolloy, rengolin

Subscribers: aemerson, rengolin, llvm-commits

Differential Revision: https://reviews.llvm.org/D24337

llvm-svn: 281324

For the common pattern (CMPZ (AND x, #bitmask), #0), we can do some more efficient instruction selection if the bitmask is one consecutive sequence of set bits (32 - clz(bm) - ctz(bm) == popcount(bm)).

1) If the bitmask touches the LSB, then we can remove all the upper bits and set the flags by doing one LSLS.
2) If the bitmask touches the MSB, then we can remove all the lower bits and set the flags with one LSRS.
3) If the bitmask has popcount == 1 (only one set bit), we can shift that bit into the sign bit with one LSLS and change the condition query from NE/EQ to MI/PL (we could also implement this by shifting into the carry bit and branching on BCC/BCS).
4) Otherwise, we can emit a sequence of LSLS+LSRS to remove the upper and lower zero bits of the mask.

1-3 require only one 16-bit instruction and can elide the CMP. 4 requires two 16-bit instructions but can elide the CMP and doesn't require materializing a complex immediate, so is also a win.

llvm-svn: 281323

Teach SimplifyLibcalls that in can treat functions annotated with
apcs, aapcs or aapcs_vfp like normal C functions if they only take
and return integer or pointer values, and the target is not iOS.

Differential Revision: https://reviews.llvm.org/D24453

llvm-svn: 281322

[llvm-cov] - Included footer "Generated by llvm-cov -- llvm version <version number>" in the coverage report.

The llvm-cov version information will be useful to the user when comparing the code coverage across different versions of llvm-cov. This patch provides the llvm-cov version information in the generated coverage report.

Differential Revision: https://reviews.llvm.org/D24457

llvm-svn: 281321

We already handle this is createSections.

llvm-svn: 281320

The changes made in r269352, r269353 and r269354 to support the 
transformation of the ldr rd,=immediate to mov introduced a regression
from 3.8 (ldr.w rd, =immediate) not supported.

This change puts support back in for ldr.w by means of a t2InstAlias for
the .w form. The .w is ignored in ARM state and propagated to the ldr in
Thumb2.

llvm-svn: 281319

This is PR30312. Info from bug page:

Both of these symbols demangle to abc::abc():
_ZN3abcC1Ev
_ZN3abcC2Ev
(These would be abc's complete object constructor and base object constructor, respectively.)
however with "abc::abc()" in the version script only one of the two receives the symbol version.

Patch fixes that.
It uses testcase created by Ed Maste (D24306).

Differential revision: https://reviews.llvm.org/D24336

llvm-svn: 281318

Summary: follow-up to https://reviews.llvm.org/D23882

Reviewers: dawn, krytarowski, labath, ki.stfu

Subscribers: beanz, mgorny, labath, ki.stfu, lldb-commits

Differential Revision: https://reviews.llvm.org/D23883
Author: Michał Górny <mgorny@gentoo.org>

llvm-svn: 281317

llvm-svn: 281316

llvm-svn: 281315

If a constant is unamed_addr and is only used within one function, we can save
on the code size and runtime cost of an indirection by changing the global's storage
to inside the constant pool. For example, instead of:

      ldr r0, .CPI0
      bl printf
      bx lr
    .CPI0: &format_string
    format_string: .asciz "hello, world!\n"

We can emit:

      adr r0, .CPI0
      bl printf
      bx lr
    .CPI0: .asciz "hello, world!\n"

This can cause significant code size savings when many small strings are used in one
function (4 bytes per string).

llvm-svn: 281314

llvm-svn: 281313

Reviewers: bkramer, ddcc, dschuff, sunfish

Subscribers: jfb, llvm-commits, dschuff

Differential Revision: https://reviews.llvm.org/D24497

llvm-svn: 281312

The alias to the array element is read-only and a primitive type (pointer),
therefore use the value directly instead of a reference to it.

llvm-svn: 281311

Step around a gcc pre-processor defect which causes it to fail to
parse the __has_include macro check.

llvm-svn: 281310

llvm-svn: 281309

Differential Revision: https://reviews.llvm.org/D23764

llvm-svn: 281308

This patch extends readability-container-size-empty check allowing it to produce
warnings not only for STL containers, but also for containers, which provide two
functions matching following signatures:

* `size_type size() const;`
* `bool empty() const;`

Where `size_type` can be any kind of integer type.

This functionality was proposed in https://llvm.org/bugs/show_bug.cgi?id=26823
by Eugene Zelenko.

Approval: alexfh

Reviewers: alexfh, aaron.ballman, Eugene.Zelenko

Subscribers: etienneb, Prazek, hokein, xazax.hun, cfe-commits

Differential Revision: https://reviews.llvm.org/D24349

llvm-svn: 281307

hwloop regression tests. These tests pass locally; will be investigating
where these differences come from.

llvm-svn: 281306

llvm-svn: 281305

descriptions now tag add instructions, and the Hexagon backend is using this to
identify loop induction statements.

Patch by Sam Parker and Sjoerd Meijer.

Differential Revision: https://reviews.llvm.org/D23601

llvm-svn: 281304

This prevents a compiler crash.

llvm-svn: 281303

Optimized (truncate (assertzext x) to i1) and anyext i1 to i8/16/32.
Optimization of this patterns is a one more step towards i1 optimization on AVX-512.

Differential Revision: https://reviews.llvm.org/D24456

llvm-svn: 281302

We currently return 4 for stackmaps and patchpoints, which is very optimistic
and can in rare cases cause the branch relaxation pass to fail to relax certain
branches.

This patch causes getInstSizeInBytes to return a pessimistic estimate of the
size as the number of bytes requested in the stackmap/patchpoint. In the future,
we could provide a more accurate estimate by sharing some of the logic in
AArch64::LowerSTACKMAP/PATCHPOINT.

Fixes part of https://llvm.org/bugs/show_bug.cgi?id=28750

Differential Revision: https://reviews.llvm.org/D24073

llvm-svn: 281301

[X86] Remove masked shufpd/shufps intrinsics and autoupgrade to native vector shuffles. They were removed from clang previously but accidentally left in the backend.

llvm-svn: 281300

llvm-svn: 281299

llvm-svn: 281298

Patch by:	Alfred Perlstein <alfred@FreeBSD.org>

llvm-svn: 281297

Differential Revision:	https://reviews.llvm.org/D24494

llvm-svn: 281296

llvm-svn: 281295

Summary: This change adds "java" to the list of known extensions that clang-format supports.

Patch by Luis Hector Chavez

Reviewers: djasper

Subscribers: srhines, cfe-commits

Differential Revision: https://reviews.llvm.org/D24401

llvm-svn: 281294

Original commit message:

Add -fdiagnostics-show-hotness

Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region.  This uses PGO and allows
filtering of the optimization remarks by relevance.  The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334

The general goal is to produce a YAML file with the remarks.  Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.

That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)

For the record, Hal has already expressed support for the idea of this
patch on IRC.

Differential Revision: https://reviews.llvm.org/D23284

llvm-svn: 281293