On failing to find sequences that can be converted into dual macs,
try to find sequential 16-bit loads that are used by muls which we
can then use smultb, smulbt, smultt with a wide load.

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

llvm-svn: 342210

As preparation for LoopInterchange becoming a loop pass, it needs to
preserve ScalarEvolution. Even though interchanging should not change
the trip count of the loop, it modifies loop entry, latch and exit
blocks.

I added -verify-scev to some loop interchange tests, but the verification does
not catch problems caused by missing invalidation of SE in loop interchange, as
the trip counts themselves do not change. So there might be potential to
make the SE verification covering more stuff in the future.

Reviewers: mkazantsev, efriedma, karthikthecool

Reviewed By: efriedma

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

llvm-svn: 342209

Summary:
This patch adds some symbol tag checks before using the `IPDBRawSymbol`
interface to improve safety and readability.

Reviewers: zturner

Reviewed By: zturner

Subscribers: lldb-commits, stella.stamenova

Tags: #lldb

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

llvm-svn: 342208

After recent improvements which makes better use of LOC instead of IPM, the
TTI cost functions also needs to be updated to reflect this.

This involves sext, zext and xor of i1.

The tests were updated so that for z13 the new costs are expected, while the
old costs are still checked for on zEC12.

Review: Ulrich Weigand
https://reviews.llvm.org/D51339

llvm-svn: 342207

The PE spec says that they will be separated by spaces, but link.exe
handles it just fine if they are separated by null bytes as well.

This adds tests to the lld repo, with the actual functional change
in LLVM in SVN r342204.

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

llvm-svn: 342206

When declaring the pair variable as "auto Pair : Map", it is
effectively declared as
std::pair<std::pair<StringRef, uint32_t>, std::vector<Chunk *>>.
This effectively does a full, shallow copy of the Chunk vector,
just to be thrown away after each iteration.

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

llvm-svn: 342205

When reading directives from a .drectve section, the directives are
tokenized as a normal windows command line. However in these cases,
link.exe allows the directives to be separated by null bytes, not only by
spaces.

A test case for this change will be added in the lld repo.

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

llvm-svn: 342204

[InstCombine] Add some test cases for (add (sext x), (sext y)) --> (sext (add int x, y)) and (mul (sext x), (sext y)) --> (sext (mul x, y)). NFC

llvm-svn: 342203

llvm-svn: 342202

Fix for the buildbot failure http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/23635
from the commit (r342197) of https://reviews.llvm.org/D50820.

llvm-svn: 342201

Summary:
Before this change, we only emit the XRay attributes in LLVM IR when the
-fxray-instrument flag is provided. This may cause issues with thinlto
when the final binary is being built/linked with -fxray-instrument, and
the constitutent LLVM IR gets re-lowered with xray instrumentation.

With this change, we can honour the "never-instrument "attributes
provided in the source code and preserve those in the IR. This way, even
in thinlto builds, we retain the attributes which say whether functions
should never be XRay instrumented.

This change addresses llvm.org/PR38922.

Reviewers: mboerger, eizan

Subscribers: mehdi_amini, dexonsmith, cfe-commits, llvm-commits

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

llvm-svn: 342200

There is a bit of code at the end of AddDeclaration that should be run on
every exit of the function.  However, there was an early exit beforehand
that could be triggered, which causes a small amount of data to skip the
hashing, leading to false positive mismatch.  Use a separate function so
that this code is always run.

llvm-svn: 342199

llvm-svn: 342198

Summary:
[VPlan] Implement vector code generation support for simple outer loops.

Context: Patch Series #1 for outer loop vectorization support in LV  using VPlan. (RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-December/119523.html).
                                                          
This patch introduces vector code generation support for simple outer loops that are currently supported in the VPlanNativePath. Changes here essentially do the following:

  - force vector code generation using explicit vectorize_width

  - add conservative early returns in cost model and other places for VPlanNativePath

  - add code for setting up outer loop inductions 

  - support for widening non-induction PHIs that can result from inner loops and uniform conditional branches

  - support for generating uniform inner branches

We plan to add a handful C outer loop executable tests once the initial code generation support is committed. This patch is expected to be NFC for the inner loop vectorizer path. Since we are moving in the direction of supporting outer loop vectorization in LV, it may also be time to rename classes such as InnerLoopVectorizer. 

Reviewers: fhahn, rengolin, hsaito, dcaballe, mkuper, hfinkel, Ayal

Reviewed By: fhahn, hsaito

Subscribers: dmgreen, bollu, tschuett, rkruppe, rogfer01, llvm-commits

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

llvm-svn: 342197

Don't hardcode align 8.

Fixes a bot failure:
http://lab.llvm.org:8011/builders/clang-cmake-armv8-full/builds/6373

llvm-svn: 342196

The location of implicit captures has changed. Update a use-after-move
checker test to reflect that.

This fixes a bot failure:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/36500

llvm-svn: 342195

A lambda's closure is initialized when the lambda is declared. For
implicit captures, the initialization code emitted from EmitLambdaExpr
references source locations *within the lambda body* in the function
containing the lambda. This results in a poor debugging experience: we
step to the line containing the lambda, then into lambda, out again,
over and over, until every capture's field is initialized.

To improve stepping behavior, assign the starting location of the lambda
to expressions which initialize an implicit capture within it.

rdar://39807527

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

llvm-svn: 342194

Fixes missing `llvm::LLVMContext::~LLVMContext()` symbols w/
`BUILD_SHARED_LIBS`.

llvm-svn: 342193

incomplete type.

Also improve the diagnostics for similar situations.

llvm-svn: 342192

Patch by Thomas Roughton.

This patch adds support for linking with multiple definitions to LLD's
COFF driver, in line with link.exe's /force:multiple option.

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

llvm-svn: 342191

I started from a clean slate to do the checkin, but forgot to svn add the new files.
Do that now.

Also add the one new source file to CMakeLists.txt

llvm-svn: 342190

Summary:
I accidentally left this behind in D50306, and it causes a build warning
when I build with gcc7.

Subscribers: arsenm, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, t-tye, llvm-commits

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

Change-Id: I30f7a47047e9d9d841f652da66d2fea19e74842c
llvm-svn: 342189

llvm-svn: 342188

Summary:
Place global arrays in comdat sections with their associated functions.
This makes sure they are stripped along with the functions they
reference, even on the BFD linker.

Reviewers: eugenis

Reviewed By: eugenis

Subscribers: eraman, hiraditya, llvm-commits

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

llvm-svn: 342186

This change allows you to write a new breakpoint type where the
logic for setting breakpoints is determined by a Python callback
written using the SB API's.

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

llvm-svn: 342185

The last, non-canonical variant:
https://godbolt.org/z/aCMsPk
https://rise4fun.com/Alive/I6f

It can only happen due to the extra use on the inner shift.
But here it is ok.

https://bugs.llvm.org/show_bug.cgi?id=38708

llvm-svn: 342184

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

llvm-svn: 342183

Fixes build for me.
Refs. D52054

[215/217] Linking CXX executable unittests/tools/llvm-exegesis/X86/LLVMExegesisX86Tests
FAILED: unittests/tools/llvm-exegesis/X86/LLVMExegesisX86Tests
: && /usr/bin/g++  -pipe -O2 -g0 -UNDEBUG -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -pipe -O2 -g0 -UNDEBUG  -fuse-ld=lld -Wl,--color-diagnostics -Wl,-allow-shlib-undefined     -Wl,-O3 -Wl,--gc-sections unittests/tools/llvm-exegesis/X86/CMakeFiles/LLVMExegesisX86Tests.dir/AssemblerTest.cpp.o unittests/tools/llvm-exegesis/X86/CMakeFiles/LLVMExegesisX86Tests.dir/AnalysisTest.cpp.o unittests/tools/llvm-exegesis/X86/CMakeFiles/LLVMExegesisX86Tests.dir/SnippetGeneratorTest.cpp.o unittests/tools/llvm-exegesis/X86/CMakeFiles/LLVMExegesisX86Tests.dir/RegisterAliasingTest.cpp.o unittests/tools/llvm-exegesis/X86/CMakeFiles/LLVMExegesisX86Tests.dir/TargetTest.cpp.o  -o unittests/tools/llvm-exegesis/X86/LLVMExegesisX86Tests  -Wl,-rpath,/build/llvm-build-GCC-release/lib lib/libLLVMMC.so.8svn lib/libLLVMMCParser.so.8svn lib/libLLVMObject.so.8svn lib/libLLVMSymbolize.so.8svn lib/libLLVMX86CodeGen.so.8svn lib/libLLVMX86AsmParser.so.8svn lib/libLLVMX86AsmPrinter.so.8svn lib/libLLVMX86Desc.so.8svn lib/libLLVMX86Disassembler.so.8svn lib/libLLVMX86Info.so.8svn lib/libLLVMX86Utils.so.8svn lib/libLLVMSupport.so.8svn -lpthread lib/libgtest_main.so.8svn lib/libgtest.so.8svn -lpthread lib/libLLVMExegesis.so.8svn lib/libLLVMExegesisX86.so.8svn && :
ld.lld: error: undefined symbol: llvm::LLVMContext::~LLVMContext()
>>> referenced by AssemblerTest.cpp
>>>               unittests/tools/llvm-exegesis/X86/CMakeFiles/LLVMExegesisX86Tests.dir/AssemblerTest.cpp.o:(exegesis::(anonymous namespace)::X86MachineFunctionGeneratorTest_DISABLED_JitFunction_Test::TestBody())

ld.lld: error: undefined symbol: llvm::LLVMContext::~LLVMContext()
>>> referenced by AssemblerTest.cpp
>>>               unittests/tools/llvm-exegesis/X86/CMakeFiles/LLVMExegesisX86Tests.dir/AssemblerTest.cpp.o:(exegesis::(anonymous namespace)::X86MachineFunctionGeneratorTest_DISABLED_JitFunctionXOR32rr_Default_Test::TestBody())

ld.lld: error: undefined symbol: llvm::LLVMContext::~LLVMContext()
>>> referenced by AssemblerTest.cpp
>>>               unittests/tools/llvm-exegesis/X86/CMakeFiles/LLVMExegesisX86Tests.dir/AssemblerTest.cpp.o:(void exegesis::MachineFunctionGeneratorBaseTest::Check<int, int, int, int, int, int, int, int>(exegesis::ExegesisTarget const&, llvm::ArrayRef<unsigned int>, llvm::MCInst, int, int, int, int, int, int, int, int))

ld.lld: error: undefined symbol: llvm::LLVMContext::~LLVMContext()
>>> referenced by AssemblerTest.cpp
>>>               unittests/tools/llvm-exegesis/X86/CMakeFiles/LLVMExegesisX86Tests.dir/AssemblerTest.cpp.o:(exegesis::(anonymous namespace)::X86MachineFunctionGeneratorTest_DISABLED_JitFunctionMOV32ri_Test::TestBody())
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

llvm-svn: 342182

Summary:
This patch adds a framework for adding descriptions to the command completions we provide.
It also adds descriptions for completed top-level commands so that we can test this code.

Completions are in general supposed to be displayed alongside the completion itself. The descriptions
can be used to provide additional information about the completion to the user. Examples for descriptions
are function signatures when completing function calls in the expression command or the binary name
when providing completion for a symbol.

There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective
APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be
used), so that's why I still had to change some function signatures. Also, as the old API only passes around a
list of matches, and the descriptions are for these functions just another list, I had to add some code that
essentially just ensures that both lists are always the same side (e.g. all the manual calls to
`descriptions->AddString(X)` below a `matches->AddString(Y)` call).

The initial command descriptions that come with this patch are just reusing the existing
short help that is already added in LLDB.

An example completion with descriptions looks like this:
```
(lldb) pl
Available completions:
        platform -- Commands to manage and create platforms.
        plugin   -- Commands for managing LLDB plugins.
```

Reviewers: #lldb, jingham

Reviewed By: #lldb, jingham

Subscribers: jingham, JDevlieghere, lldb-commits

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

llvm-svn: 342181

See rL342148

This probably only shows up in BUILD_SHARED_LIBS=ON builds
which might explain how it crept in.

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

llvm-svn: 342180

These functions previously passed nil for the location, which always resulted in a crash.

This is a signature breaking change, but I cannot see how they could have been used before.

Patch by Ben Clayton!

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

llvm-svn: 342179

llvm-svn: 342178

Summary:
When someone writes

  #include "<some_file>"

or

  #include " some_file "

the compiler returns "file not fuond..." with fonts and quotes that may
make it hard to see there are excess quotes or surprising bytes in the
filename.  Assuming that files are usually logically named and start and
end with an alphanumeric character, we can check for the file's
existence by stripping the non-alphanumeric leading or trailing
characters.  If the file is found, emit a non-fatal error with a
FixItHint.

Patch by Christy Lee!

Reviewers: aaron.ballman, erikjv, rsmith

Reviewed By: rsmith

Subscribers: lebedev.ri, xbolva00, sammccall, modocache, erikjv, aaron.ballman, cfe-commits

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

llvm-svn: 342177

[MachineInstr] In addRegisterKilled and addRegisterDead, don't remove operands from inline assembly instructions if they have an associated flag operand.

INLINEASM instructions use extra operands to carry flags. If a register operand is removed without removing the flag operand, then the flags will no longer make sense.

This patch fixes this by preventing the removal when a flag operand is present.

The included test case was generated by MS inline assembly. Longer term maybe we should fix the inline assembly parsing to not generate redundant operands.

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

llvm-svn: 342176

When replacing a named register input to the appropriately sized
sub/super-register. In the case of a 64-bit value being assigned to a
register in 32-bit mode, match GCC's assignment.

Reviewers: eli.friedman, craig.topper

Subscribers: nickdesaulniers, llvm-commits, hiraditya

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

llvm-svn: 342175

llvm-svn: 342174

Summary:
It is sometimes important to check that some newly-computed value
is non-negative and only n bits wide (where n is a variable.)
There are many ways to check that:
https://godbolt.org/z/o4RB8D
The last variant seems best?
(I'm sure there are some other variations i haven't thought of..)

More complicated, canonical pattern:
https://rise4fun.com/Alive/uhA

We do need to have two `switch()`'es like this,
to not mismatch the swappable predicates.

https://bugs.llvm.org/show_bug.cgi?id=38708

Reviewers: spatel, craig.topper, RKSimon

Reviewed By: spatel

Subscribers: llvm-commits

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

llvm-svn: 342173

This adds DebugCounter support to the PartiallyInlineLibCalls pass,
which should make debugging/automated bisection easier in the future.

Patch by Zhizhou Yang!

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

llvm-svn: 342172

Came up in https://reviews.llvm.org/D52001#1233827
While we don't do a good job here, we at least want to make
sure that we don't have any inf-loops.

llvm-svn: 342171

Patch by Zhizhou Yang!

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

llvm-svn: 342170