The TBB and TBH instructions in Thumb-2 allow jump tables to be compressed into sequences of bytes or shorts respectively. These instructions do not exist in Thumb-1, however it is possible to synthesize them out of a sequence of other instructions.

It turns out this sequence is so short that it's almost never a lose for performance and is ALWAYS a significant win for code size.

TBB example:
Before: lsls r0, r0, #2    After: add  r0, pc
        adr  r1, .LJTI0_0         ldrb r0, [r0, #6]
        ldr  r0, [r0, r1]         lsls r0, r0, #1
        mov  pc, r0               add  pc, r0
  => No change in prologue code size or dynamic instruction count. Jump table shrunk by a factor of 4.

The only case that can increase dynamic instruction count is the TBH case:

Before: lsls r0, r4, #2    After: lsls r4, r4, #1
        adr  r1, .LJTI0_0         add  r4, pc
        ldr  r0, [r0, r1]         ldrh r4, [r4, #6]
        mov  pc, r0               lsls r4, r4, #1
                                  add  pc, r4
  => 1 more instruction in prologue. Jump table shrunk by a factor of 2.

So there is an argument that this should be disabled when optimizing for performance (and a TBH needs to be generated). I'm not so sure about that in practice, because on small cores with Thumb-1 performance is often tied to code size. But I'm willing to turn it off when optimizing for performance if people want (also note that TBHs are fairly rare in practice!)

llvm-svn: 284580

Gcc prints error if elements of left and right parts of a shift have different
sizes. This patch is provided the GCC compatibility.

Patch by Vladimir Yakovlev.

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

llvm-svn: 284579

This will get the same ConstantSDNode scalar or vector splat value as the current separate dyn_cast<ConstantSDNode> / isVector() approach.

llvm-svn: 284578

This is a followup to regression introduced in r284284.

This should fix our libstdc++ modules builds.

https://reviews.llvm.org/D25678

Reviewed by Richard Smith!

llvm-svn: 284577

llvm-svn: 284576

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

llvm-svn: 284575

[DAGCombine] Generalize distributeTruncateThroughAnd to work with any non-opaque constant or constant vector

llvm-svn: 284574

Summary:
Introduces a separate target for comment manipulation.
Currently, comment manipulation is in BreakableComment.cpp.
Towards implementing comment reflowing, we want to factor out the
comment-related functionality, so it can be reused.
Start simple by just moving out getLineCommentIndentPrefix.

Patch by Krasimir Georgiev!

Reviewers: djasper

Subscribers: klimek, beanz, mgorny, modocache

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

llvm-svn: 284573

llvm-svn: 284572

This renames the function for checking FP function attribute values and also
adds more build attribute tests (which are in separate files because build
attributes are set per file).

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

llvm-svn: 284571

msc18 doesn't recognize "using BaseT::BaseT;"

  llvm\include\llvm/ADT/DenseSet.h(213) : error C2875: using-declaration causes a multiple declaration of 'BaseT'
          llvm\include\llvm/ADT/DenseSet.h(214) : see reference to class template instantiation 'llvm::DenseSet<ValueT,ValueInfoT>' being compiled
  llvm\include\llvm/ADT/DenseSet.h(231) : error C2875: using-declaration causes a multiple declaration of 'BaseT'
          llvm\include\llvm/ADT/DenseSet.h(232) : see reference to class template instantiation 'llvm::SmallDenseSet<ValueT,InlineBuckets,ValueInfoT>' being compiled

llvm-svn: 284570

[AVX-512] Teach isel lowering that a subvector broadcast being inserted into both halves of a 512-bit vector can be combined into a larger subvector broadcast.

Summary:
This allows us to create broadcasts of 128-bit vector loads into 512-bit vectors.

New patterns added to support 8-bit and 16-bit vector types and v2f64/v2i64->v8f64/v8i64 without DQI instructions.

There also fallback patterns when the load can't be folded. These patterns are a little complex as we first need to insert the lower 128-bits into the second 128-bits using a zmm subvector insert instruction. We need to use a zmm insert in case VLX isn't available. Then use another zmm sub vector insert to take those 256-bits and insert them into the upper bits. Since we used a zmm insert to create the 256-bits we also need to do a extract_subreg to get just the lower 256-bits to pass to the second insert.

The outer insert for the fallback patterns should have its type correct because eventually we should also supported masked operations here too. So we need a DQI and a NoDQI version of the v16f32/v16i32 patterns.

Reviewers: RKSimon, delena, igorb

Subscribers: llvm-commits

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

llvm-svn: 284567

llvm-svn: 284566

This patch is causing a lot of issues on bots that I didn't see in local testing. I'm going to have to work on this. Reverting for now while I sort it out.

llvm-svn: 284565

llvm-svn: 284564

Revert r284545 again as the regression in ppc still exists. There is bug in MBPI exposed by th patch.

Also update the section.ll to fix non-x86 failure.

llvm-svn: 284563

llvm-svn: 284557

llvm-svn: 284556

Need to gate cxx linker adding driver-mode flag based on the linker being clang.

llvm-svn: 284555

Example of output:
COVERAGE:
COVERED: in DSO2(int) /pathto/DSO2.cpp:6
COVERED: in DSO2(int) /pathto/DSO2.cpp:8
COVERED: in DSO1(int) /pathto/DSO1.cpp:6
COVERED: in DSO1(int) /pathto/DSO1.cpp:8
COVERED: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:16
COVERED: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:19
COVERED: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:25
COVERED: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:26
MODULE_WITH_COVERAGE: /pathto/libLLVMFuzzer-DSO1.so
UNCOVERED_LINE: in DSO1(int) /pathto/DSO1.cpp:9
UNCOVERED_FUNC: in Uncovered1()
MODULE_WITH_COVERAGE: /pathto/libLLVMFuzzer-DSO2.so
UNCOVERED_LINE: in DSO2(int) /pathto/DSO2.cpp:9
UNCOVERED_FUNC: in Uncovered2()
MODULE_WITH_COVERAGE: /pathto/LLVMFuzzer-DSOTest
UNCOVERED_LINE: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:21
UNCOVERED_LINE: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:27
UNCOVERED_FILE: /pathto/DSOTestExtra.cpp

Several things are not perfect here:
* we are using objdump+awk instead of sancov because sancov does not support DSOs yet.
* this breaks in the presence of ASAN_OPTIONS=strip_path_prefix=...
  (need to implement another API to get the module name by PC)

llvm-svn: 284554

Summary:
Previously we had to split out a lot of our tests into a test that
checked only immediate errors and a test that checked only deferred
errors.  This was because, if you emitted any immediate errors, we
wouldn't run codegen, where the deferred errors were emitted.

We've fixed this, and now emit deferred errors during sema.  This lets
us merge a bunch of tests, and lets us convert some other tests to
-fsyntax-only.

Reviewers: tra

Subscribers: cfe-commits

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

llvm-svn: 284553

Summary:
If a user has their shell set to a non-POSIX conferment shell the TestTerminal.py tests fail because the shell blurb constructed here may not work in their shell.

In my specific case fish-shell (The Friendly Interactive Shell - http://fishshell.com) does not support $?, it instead uses $status (because it is friendly).

This patch removes the assumption of your default shell by running the constructed bash command via "/bin/bash -c ...". This should be safer for users mutating their shell environment.

Reviewers: tfiala

Subscribers: joerg, lldb-commits

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

llvm-svn: 284552

Summary:
CMake has no builtin mechanism for cache invalidation. As a general convention you want to not expand user-specified variables in other cached variables because they will not get updated when the user changes their specified value.

This patch moves the "-C" option for dotest.py into the LLDB_TEST_COMMON_ARGS and out of the CMake cache. In order to prevent issues with out-of-date cache files on builders I've added code to scrub "-C ${LLDB_TEST_COMPILER}" out of the CMake caches, by Force writing the variable. This code can be removed in a few days once the change has trickled through CI systems.

Reviewers: tfiala, labath, zturner

Subscribers: lldb-commits, mgorny

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

llvm-svn: 284551

Summary:
When building the LLDB test programs, if your CC is clang it actually isn't safe to make CXX a string replace of "clang -> clang++". This falls down on unix configurations if your compiler is clang-${version}.

A safer approach is to use the "--driver-mode=g++" option to tell clang to act like clang++.

Reviewers: tfiala, zturner, labath

Subscribers: lldb-commits

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

llvm-svn: 284550

not instantiate exception specifications of functions if they were only used in
unevaluated contexts (other than 'noexcept' expressions).

In C++17 onwards, this becomes essential since the exception specification is
now part of the function's type.

Note that this means that constructs like the following no longer work:

  struct A {
    static T f() noexcept(...);
    decltype(f()) *p;
  };

... because the decltype expression now needs the exception specification of
'f', which has not yet been parsed.

llvm-svn: 284549

Reviewers: eugenis

Subscribers: kubabrecka, llvm-commits

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

llvm-svn: 284548

[asan] Simplify calculation of stack frame layout extraction calculation of stack description into separate function.

Reviewers: eugenis

Subscribers: llvm-commits

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

llvm-svn: 284547

[asan] Append line number to variable name if line is available and in the same file as the function.

PR30498

Reviewers: eugenis

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

llvm-svn: 284546

Summary:
The original heuristic to break critical edge during machine sink is relatively conservertive: when there is only one instruction sinkable to the critical edge, it is likely that the machine sink pass will not break the critical edge. This leads to many speculative instructions executed at runtime. However, with profile info, we could model the splitting benefits: if the critical edge has 50% taken rate, it would always be beneficial to split the critical edge to avoid the speculated runtime instructions. This patch uses profile to guide critical edge splitting in machine sink pass.

The performance impact on speccpu2006 on Intel sandybridge machines:

spec/2006/fp/C++/444.namd                  25.3  +0.26%
spec/2006/fp/C++/447.dealII               45.96  -0.10%
spec/2006/fp/C++/450.soplex               41.97  +1.49%
spec/2006/fp/C++/453.povray               36.83  -0.96%
spec/2006/fp/C/433.milc                   23.81  +0.32%
spec/2006/fp/C/470.lbm                    41.17  +0.34%
spec/2006/fp/C/482.sphinx3                48.13  +0.69%
spec/2006/int/C++/471.omnetpp             22.45  +3.25%
spec/2006/int/C++/473.astar               21.35  -2.06%
spec/2006/int/C++/483.xalancbmk           36.02  -2.39%
spec/2006/int/C/400.perlbench              33.7  -0.17%
spec/2006/int/C/401.bzip2                  22.9  +0.52%
spec/2006/int/C/403.gcc                   32.42  -0.54%
spec/2006/int/C/429.mcf                   39.59  +0.19%
spec/2006/int/C/445.gobmk                 26.98  -0.00%
spec/2006/int/C/456.hmmer                 24.52  -0.18%
spec/2006/int/C/458.sjeng                 28.26  +0.02%
spec/2006/int/C/462.libquantum            55.44  +3.74%
spec/2006/int/C/464.h264ref               46.67  -0.39%

geometric mean                                   +0.20%

Manually checked 473 and 471 to verify the diff is in the noise range.

Reviewers: rengolin, davidxl

Subscribers: llvm-commits

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

llvm-svn: 284545

llvm-svn: 284544

Update test after commit r284501:
[SCEV] Make CompareValueComplexity a little bit smarter

Contributed-by: Sanjoy Das <sanjoy@playingwithpointers.com>
llvm-svn: 284543

Summary:
This pass shrink-wraps a condition to some library calls where the call
result is not used. For example:
   sqrt(val);
 is transformed to
   if (val < 0)
     sqrt(val);
Even if the result of library call is not being used, the compiler cannot
safely delete the call because the function can set errno on error
conditions.
Note in many functions, the error condition solely depends on the incoming
parameter. In this optimization, we can generate the condition can lead to
the errno to shrink-wrap the call. Since the chances of hitting the error
condition is low, the runtime call is effectively eliminated.

These partially dead calls are usually results of C++ abstraction penalty
exposed by inlining. This optimization hits 108 times in 19 C/C++ programs
in SPEC2006.

Reviewers: hfinkel, mehdi_amini, davidxl

Subscribers: modocache, mgorny, mehdi_amini, xur, llvm-commits, beanz

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

llvm-svn: 284542

Summary:
The original heuristic to break critical edge during machine sink is relatively conservertive: when there is only one instruction sinkable to the critical edge, it is likely that the machine sink pass will not break the critical edge. This leads to many speculative instructions executed at runtime. However, with profile info, we could model the splitting benefits: if the critical edge has 50% taken rate, it would always be beneficial to split the critical edge to avoid the speculated runtime instructions. This patch uses profile to guide critical edge splitting in machine sink pass.

The performance impact on speccpu2006 on Intel sandybridge machines:

spec/2006/fp/C++/444.namd                  25.3  +0.26%
spec/2006/fp/C++/447.dealII               45.96  -0.10%
spec/2006/fp/C++/450.soplex               41.97  +1.49%
spec/2006/fp/C++/453.povray               36.83  -0.96%
spec/2006/fp/C/433.milc                   23.81  +0.32%
spec/2006/fp/C/470.lbm                    41.17  +0.34%
spec/2006/fp/C/482.sphinx3                48.13  +0.69%
spec/2006/int/C++/471.omnetpp             22.45  +3.25%
spec/2006/int/C++/473.astar               21.35  -2.06%
spec/2006/int/C++/483.xalancbmk           36.02  -2.39%
spec/2006/int/C/400.perlbench              33.7  -0.17%
spec/2006/int/C/401.bzip2                  22.9  +0.52%
spec/2006/int/C/403.gcc                   32.42  -0.54%
spec/2006/int/C/429.mcf                   39.59  +0.19%
spec/2006/int/C/445.gobmk                 26.98  -0.00%
spec/2006/int/C/456.hmmer                 24.52  -0.18%
spec/2006/int/C/458.sjeng                 28.26  +0.02%
spec/2006/int/C/462.libquantum            55.44  +3.74%
spec/2006/int/C/464.h264ref               46.67  -0.39%

geometric mean                                   +0.20%

Manually checked 473 and 471 to verify the diff is in the noise range.

Reviewers: rengolin, davidxl

Subscribers: llvm-commits

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

llvm-svn: 284541

llvm-svn: 284540

(accidentally removed this from my previous change when I was rejecting
some clang-format formatting... )

llvm-svn: 284539

llvm-svn: 284538

dwarfdump: -summarize-types: print a short summary (unqualified type name, hash, length) of type units rather than dumping contents

This is just a quick utility handy for getting rough summaries of types
in a given object or dwo file. I've been using it to investigate the
amount of type info redundancy across a project build, for example.

llvm-svn: 284537

The custom lowering is pretty straightforward: basically, just AND
together the two halves of a <4 x i32> compare.

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

llvm-svn: 284536

This is in line with other places of GVN (e.g. load coercion
logic).

llvm-svn: 284535

llvm-svn: 284534