It's failing due to Hexagon calling convention lowering being broken (empty
structs are not passed even if they have nontrivial destructors / copy ctors).

llvm-svn: 302825

Reviewers: EricWF

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

llvm-svn: 302824

The erase/remove from parent methods now use a switch table to remove
themselves from their appropriate parent ilist.

The copyAttributesFrom method is now completely non-virtual, since we
only ever copy attributes from a global of the appropriate type.

Pre-requisite to de-virtualizing Value to save a vptr
(https://reviews.llvm.org/D31261).

NFC

llvm-svn: 302823

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

llvm-svn: 302822

llvm-svn: 302821

Updates the MSP430 target to generate EABI-compatible libcall names.
As a byproduct, adjusts the hardware multiplier options available in
the MSP430 target, adds support for promotion of the ISD::MUL operation
for 8-bit integers, and correctly marks R11 as used by call instructions.

Patch by Andrew Wygle.

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

llvm-svn: 302820

The testcase in PR32984 shows a non linear compile time increase
after a change that made the LoopUnroll pass more aggressive
(increasing the threshold).

My profiling shows all the time of PHI elimination goes to
llvm::LiveVariables::addNewBlock. This is because we keep
Defs/Kills registers in a SmallSet and vfind(const T &V); is O(N).

Switching to a DenseSet reduces the time spent in the pass from
297 seconds to 97 seconds. Profiling still shows a lot of time is
spent iterating the data structure, so I guess there's room for
improvement.

Dan tells me GCC uses real set operations for live registers and
it takes no-time on this testcase. Matthias points out we might
want to switch all this to LiveIntervalAnalysis so it's not entirely
sure if a rewrite is worth it.

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

llvm-svn: 302819

llvm-svn: 302818

in list-initialization, run cleanups for the default argument after each
iteration of the initialization loop.

We previously only ran the destructor for any temporary once, at the end of the
complete loop, rather than once per iteration!

Re-commit of r302750, reverted in r302776.

llvm-svn: 302817

llvm-svn: 302816

llvm-svn: 302815

We don't use it and it was removed in gfx9, and the encoding
bit repurposed.

Additionally actually using it requires changing the output register
class, which wasn't done anyway.

llvm-svn: 302814

This allows folding source modifiers in more f16 cases.
Makes it easier to select per-component packed neg modifiers.

llvm-svn: 302813

Earlier fix D32572 introduced a bug where live-ins were calculated
for basic block instead of scheduling region. This change fixes it.

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

llvm-svn: 302812

The approach I followed was to emit the remark after getTreeCost concludes
that SLP is profitable.  I initially tried emitting them after the
vectorizeRootInstruction calls in vectorizeChainsInBlock but I vaguely
remember missing a few cases for example in HorizontalReduction::tryToReduce.

ORE is placed in BoUpSLP so that it's available from everywhere (notably
HorizontalReduction::tryToReduce).

We use the first instruction in the root bundle as the locator for the remark.
In order to get a sense how far the tree is spanning I've include the size of
the tree in the remark.  This is not perfect of course but it gives you at
least a rough idea about the tree.  Then you can follow up with -view-slp-tree
to really see the actual tree.

llvm-svn: 302811

This patch is the first in a series of patches to provide code gen for
doing compares in GPRs when the compare result is required in a GPR.

It adds the infrastructure to select GPR sequences for i1->i32 and i1->i64
extensions. This first patch handles equality comparison on i32 operands with
the result sign or zero extended.

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

llvm-svn: 302810

rdar://problem/27876262

llvm-svn: 302809

llvm-svn: 302808

[asan] Test 'strndup_oob_test.cc' added in r302781 fails on the clang-cmake-thumbv7-a15-full-sh bot.
Marking as unsupported on armv7l-unknown-linux-gnueabihf, same as strdup_oob_test.cc

llvm-svn: 302807

llvm-svn: 302806

After DeLICM, it is possible to have two writes of the same value to
the same location in the same statement when it determined that those
writes do not conflict (write the same value).

Teach -polly-simplify to remove one of the writes. It interferes with
the pattern matching of matrix-multiplication kernels and also seem
to not be optimized away by LLVM.

The algorthm is simple, has O(n^2) behaviour (n = max number of
MemoryAccesses in a statement) and only matches the most obvious cases,
but seem to be enough to pattern-match Boost ublas gemm.

Not handled cases include:
- StoreInst instructions (a.k.a. explicit writes), since the value might
  be loaded or overwritten between the two stores.
- PHINode, especially LCSSA, when the PHI value matches with on other's.
- Partial writes (in preparation)

llvm-svn: 302805

Missing on SandyBridge and Btver2 models

llvm-svn: 302804

A recent commit made GlobalVariable.h depend on intrinsics generation, so (I
think) it needs to be in the lower-level module. I'll confirm with others, but
this should fix the bots.

llvm-svn: 302803

Mark LWG#2782 as complete. No functionality change; we already do this. Just added a few more tests.

llvm-svn: 302802

Also remove a confused stable-runtimes requirement.

llvm-svn: 302801

Replace a nested namespace used for overload resolution with a struct. Richard Smith says that using the namespace results in an ODR violation, but I disagree. Nevertheless, the struct works just as well.

llvm-svn: 302800

Mark LWG#2850 as complete. No functionality change; we had tests that covered it already. Just added comments to the tests. Thanks to K-ballo for the heads up.

llvm-svn: 302799

Mark LWG#2796 as complete. No functionality change; we had tests that covered it already. Just added comments to the tests

llvm-svn: 302798

type is a TemplateSpecializationType or InjectedClassNameType

Fixes PR30847. Partially fixes PR20973 (first position only).

PR17614 is still not working, its expression has the dependent
builtin type. We'll have to teach the completion engine how to "resolve"
dependent expressions to fix it.

rdar://29818301

llvm-svn: 302797

completion results for records

llvm-svn: 302796

Thanks to Matthew Larionov <matthewtff@gmail.com>

llvm-svn: 302795

This patch extends llvm-ir to allow attributes to be set on global variables.
An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html
A key part of that proposal was to extend LLVM-IR to carry attributes on global variables.
This generic feature could be useful for multiple purposes.
In our present context, it would be useful to carry user specified sections for bss/rodata/data.

Reviewed by: Jonathan Roelofs, Reid Kleckner
Differential Revision: https://reviews.llvm.org/D32009

llvm-svn: 302794

Now it handle by TableGen.

llvm-svn: 302793

Testcase itself depends on .text section location, which was orphan earlier.

Suggested by Rafael Espíndola

llvm-svn: 302792

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

llvm-svn: 302791

Introduce LoopVectorizationPlanner.executePlan(), replacing ILV.vectorize() and
refactoring ILV.vectorizeLoop(). Method collectDeadInstructions() is moved from
ILV to LVP. These changes facilitate building VPlans and using them to generate
code, following https://reviews.llvm.org/D28975 and its tentative breakdown.

Method ILV.createEmptyLoop() is renamed ILV.createVectorizedLoopSkeleton() to
improve clarity; it's contents remain intact.

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

llvm-svn: 302790

Marking it as unsupported for now to hopefully make the bot green.

llvm-svn: 302789

Make sure MSan doesn't miss a bug comparing two integers with defined low bits.

llvm-svn: 302788

It turned out that MSan was incorrectly calculating the shadow for int comparisons: it was done by truncating the result of (Shadow1 OR Shadow2) to i1, effectively rendering all bits except LSB useless.
This approach doesn't work e.g. in the case where the values being compared are even (i.e. have the LSB of the shadow equal to zero).
Instead, if CreateShadowCast() has to cast a bigger int to i1, we replace the truncation with an ICMP to 0.

This patch doesn't affect the code generated for SPEC 2006 binaries, i.e. there's no performance impact.

For the test case reported in PR32842 MSan with the patch generates a slightly more efficient code:

  orq     %rcx, %rax
  jne     .LBB0_6
, instead of:

  orl     %ecx, %eax
  testb   $1, %al
  jne     .LBB0_6

llvm-svn: 302787

llvm-svn: 302786