Fix duplicate suggestions after an ambiguous command

Summary:
So far lldb is printing this when it finds an ambiguous command:
```
(lldb) g
Ambiguous command 'g'. Possible matches:
        gdb-remote
        gui
        gdb-remote
        gui
```
The duplicates come from the fact that we call the same query twice with the same parameters
and add it to the same list. This patch just removes the second query call to `GetCommandObject`.

As `GetCommandObject` is const and the name parameter is also not modified, this shouldn't break
anything else. I didn't merge the remaining if statement into the else as I think otherwise the
`if obj==nullptr do X else Y` pattern in there becomes hard to recognize.

Reviewers: davide

Reviewed By: davide

Subscribers: lldb-commits

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

llvm-svn: 338043

[COFF] clean up global resources after completion

Patch by Andrew Kelley.

Previously, running lld::coff::link() twice in the same process would
access stale pointers because of these global variables not being reset.
After this patch, lld::coff::link() can be called any number of times,
just like its ELF and MACH-O counterparts.

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

llvm-svn: 338042

[CodeGen][ObjC] Make block copy/dispose helper functions exception-safe.

When an exception is thrown in a block copy helper function, captured
objects that have previously been copied should be destructed or
released. Similarly, captured objects that are yet to be released should
be released when an exception is thrown in a dispose helper function.

rdar://problem/42410255

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

llvm-svn: 338041

Don't print two errors for unknown commands.

Summary:
We always print two error messages when we hit an unknown command. As the function
`CommandInterpreter::HandleCommand` that prints the second error message unconditionally called the `CommandInterpreter::ResolveCommandImpl` before (which prints the first error message), we can just remove
that second error message.

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

Reviewers: labath

Reviewed By: labath

Subscribers: labath, lldb-commits

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

llvm-svn: 338040

[DEBUGINFO, NVPTX] Emit correct debug information for local variables.

Summary:
NVPTX target dos not use register-based frame information. Instead it
relies on the artificial local_depot that is used instead of the frame
and the data for variables must be emitted relatively to this
local_depot.

Reviewers: tra, jlebar, echristo

Subscribers: jholewinski, aprantl, JDevlieghere, llvm-commits

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

llvm-svn: 338039

[InstCombine] add tests for udiv with common factor; NFC

This fold is mentioned in PR38239:
https://bugs.llvm.org/show_bug.cgi?id=38239

The general case probably belongs in -reassociate, but given that we do
basic reassociation optimizations similar to this in instcombine already,
we might as well be consistent within instcombine and handle this pattern?

llvm-svn: 338038

[clangd] Use 'const Twine&' instead of 'Twine'. NFC

To fix clang-tidy warning

llvm-svn: 338037

[DEBUGINFO, NVPTX] Set `DW_AT_frame_base` to `DW_OP_call_frame_cfa`.

Summary:
For NVPTX target the value of `DW_AT_frame_base` attribute must be set
to `DW_OP_call_frame_cfa`.

Reviewers: tra, jlebar, echristo

Subscribers: jholewinski, JDevlieghere, llvm-commits

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

llvm-svn: 338036

Revert r338027 to pacify build bot

llvm-svn: 338035

[ADT] Replace std::isprint by llvm::isPrint.

The standard library functions ::isprint/std::isprint have platform-
and locale-dependent behavior which makes LLVM's output less
predictable. In particular, regression tests my fail depending on the
implementation of these functions.

Implement llvm::isPrint in StringExtras.h with a standard behavior and
replace all uses of ::isprint/std::isprint by a call it llvm::isPrint.
The function is inlined and does not look up language settings so it
should perform better than the standard library's version.

Such a replacement has already been done for isdigit, isalpha, isxdigit
in r314883. gtest does the same in gtest-printers.cc using the following
justification:

    // Returns true if c is a printable ASCII character.  We test the
    // value of c directly instead of calling isprint(), which is buggy on
    // Windows Mobile.
    inline bool IsPrintableAscii(wchar_t c) {
      return 0x20 <= c && c <= 0x7E;
    }

Similar issues have also been encountered by Julia:
https://github.com/JuliaLang/julia/issues/7416

I noticed the problem myself when on Windows isprint('\t') started to
evaluate to true (see https://stackoverflow.com/questions/51435249) and
thus caused several unit tests to fail. The result of isprint doesn't
seem to be well-defined even for ASCII characters. Therefore I suggest
to replace isprint by a platform-independent version.

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

llvm-svn: 338034

[UnJ] Common some code. NFC

Create a processHeaderPhiOperands for analysing the instructions
in the aft blocks that must be moved before the loop.

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

llvm-svn: 338033

[OPENMP] Force OpenMP 4.5 when compiling for offloading.

If the user requested compilation for OpenMP with the offloading
support, force the version of the OpenMP standard to 4.5 by default.

llvm-svn: 338032

dwarfgen: Add support for generating the debug_str_offsets section, take 3

Previous version of this patch failed on darwin targets because of
different handling of cross-debug-section relocations. This fixes the
tests to emit the DW_AT_str_offsets_base attribute correctly in both
cases. Since doing this is a non-trivial amount of code, and I'm going
to need it in more than one test, I've added a helper function to the
dwarfgen DIE class to do it.

Original commit message follows:

The motivation for this is D49493, where we'd like to test details of
debug_str_offsets behavior which is difficult to trigger from a
traditional test.

This adds the plubming necessary for dwarfgen to generate this section.
The more interesting changes are:
- I've moved emitStringOffsetsTableHeader function from DwarfFile to
  DwarfStringPool, so I can generate the section header more easily from
  the unit test.
- added a new addAttribute overload taking an MCExpr*. This is used to
  generate the DW_AT_str_offsets_base, which links a compile unit to the
  offset table.

I've also added a basic test for reading and writing DW_form_strx forms.

Reviewers: dblaikie, JDevlieghere, probinson

Subscribers: llvm-commits, aprantl

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

llvm-svn: 338031

[test] Disable dsymutil update test on windows

Apparently, the issue with dsymutil update functionality on Windows was
that Windows doesn't like dsymutil renaming files that have open handles
to them. This disables the new accelerator test and updates the comment
in the other two test.

We should be able to enable the tests again once we updated the
implementation to use TempFile::keep() to keep the temporary files in
MachOUtils.

A big thank you to Jeremy Morse from Sony for figuring this out and
bringing it to my attention.

llvm-svn: 338030

Enable some pointer authentication instructions for aarch64 v8a targets

- Some of the v8.3 pointer authentication instruction inhabit the Hint space
- These instructions can be assembled to hint instructions which act as NOP instructions prior to v8.3
- This patch permits using the hint instructions for all v8a targets
- Also, correct the RETA{A,B} instructions to match the instruction attributes of RET (set isTerminator and isBarrier)

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

llvm-svn: 338029

[clangd] Fix unit tests for Dex

Iterators took temporary objects in constructors, objects were
invalidated when built with recent Clang which resulted in crashes.

llvm-svn: 338028

Fix raw_fd_ostream::write_impl hang with large output

On Windows when raw_fd_ostream::write_impl calls write, a 32 bit input
is required for character count. As a variable with size_t is used for
this argument on x64 integral demotion occurs. In the case of large
files an infinite loop follows.

See PR37926.

This fix allows the output of files larger than previous int32 limit.

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

Patch by Owen Reynolds

Reviewed by: zturner

llvm-svn: 338027

dwarfgen: Don't create an AsmPrinter with an invalid ObjFile lowering

The AsmPrinter created in the tests contained an uninitialized
TargetLoweringObjectFile. Things mostly worked regardless, because we
used a separate instance of that class to specify sections to emit.

This rearanges the object construction order so that we can avoid
creating two lowering objects. Instead, we properly initialize the
object in the AsmPrinter, and have the DWARF generator store a pointer
to it.

llvm-svn: 338026

[clang-tidy] Fix llvm.org/PR38315 (support type aliases in modernize-shrink-to-fit)

llvm-svn: 338025

Allow thread safety annotation lock upgrading and downgrading.

Patch thanks to Aaron Puchert!

llvm-svn: 338024

[tsan] Fix gcc pedantic warning

Fix gcc (7.2.0) pedantic warning
warning: extra ‘;’ [-Wpedantic]

Author: jasonl220 (Jason Lovett)
Review: https://reviews.llvm.org/D49817
llvm-svn: 338023

[ASTMatchers] fix the missing documentation for new decltypeType matcher

Summary: Regenerate the Matchers documentation, forgotten in the original patch.

Reviewers: alexfh, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 338022

[clangd] Fix (most) naming warnings from clang-tidy. NFC

llvm-svn: 338021

[analyzer] Fixed method to get APSInt model

Summary:
This patch replaces the current method of getting an `APSInt` from Z3's model by calling generic API method `getBitvector` instead of `Z3_get_numeral_uint64`.

By calling `getBitvector`, there's no need to handle bitvectors with bit width == 128 separately.

And, as a bonus, clang now compiles correctly with Z3 4.7.1.

Reviewers: NoQ, george.karpenkov

Reviewed By: george.karpenkov

Subscribers: xazax.hun, szepet, a.sidorin

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

llvm-svn: 338020

[mips] Sign extend i32 return values on MIPS64

Override getTypeForExtReturn so that functions returning
an i32 typed value have it sign extended on MIPS64.

Also provide patterns to get rid of unneeded sign extensions
for arithmetic instructions which implicitly sign extend
their results.

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

llvm-svn: 338019

Revert "[COFF] Use comdat shared constants for MinGW as well"

This reverts commit r337951.

While that kind of shared constant generally works fine in a MinGW
setting, it broke some cases of inline assembly that worked before:

$ cat const-asm.c
int MULH(int a, int b) {
    int rt, dummy;
    __asm__ (
        "imull %3"
        :"=d"(rt), "=a"(dummy)
        :"a"(a), "rm"(b)
    );
    return rt;
}
int func(int a) {
    return MULH(a, 1);
}
$ clang -target x86_64-win32-gnu -c const-asm.c -O2
const-asm.c:4:9: error: invalid variant '00000001'
        "imull %3"
        ^
<inline asm>:1:15: note: instantiated into assembly here
        imull __real@00000001(%rip)
                     ^

A similar error is produced for i686 as well. The same test with a
target of x86_64-win32-msvc or i686-win32-msvc works fine.

llvm-svn: 338018

[clangd] Proof-of-concept query iterators for Dex symbol index

This patch introduces three essential types of query iterators:
`DocumentIterator`, `AndIterator`, `OrIterator`. It provides a
convenient API for query tree generation and serves as a building block
for the next generation symbol index - Dex. Currently, many
optimizations are missed to improve code readability and to serve as the
reference implementation. Potential improvements are briefly mentioned
in `FIXME`s and will be addressed in the following patches.

Dex RFC in the mailing list:
http://lists.llvm.org/pipermail/clangd-dev/2018-July/000022.html

Iterators, their applications and potential extensions are explained in
detail in the design proposal:
https://docs.google.com/document/d/1C-A6PGT6TynyaX4PXyExNMiGmJ2jL1UwV91Kyx11gOI/edit#heading=h.903u1zon9nkj

Reviewers: ioeric, sammccall, ilya-biryukov

Subscribers: cfe-commits, klimek, jfb, mgrang, mgorny, MaskRay, jkorous,
arphaman

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

llvm-svn: 338017

[x86/SLH] Extract the logic to trace predicate state through calls to
a helper function with a nice overview comment. NFC.

This is a preperatory refactoring to implementing another component of
mitigation here that was descibed in the design document but hadn't been
implemented yet.

llvm-svn: 338016

[clangd] Give an example for symbol-builder usage

`global-symbol-builder` help message mentions `-executor=<string>`
option, but doesn't give any example of what the value could be

Assuming the most popular use case to be building the whole project
index, help message should probably give an example of such usage.

Reviewers: ioeric

Subscribers: cfe-commits

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

llvm-svn: 338015

[test] Do dsymutil update in place

Update the dSYM bundle in place when swapping out the accelerator
tables. This should unbreak the windows bot that have been failing with
an access denied.

llvm-svn: 338014

Allow users of the GCOV API to extend the FileInfo class to implement custom output formats

Summary:
The GCOV API can be used to parse gcda/gcno files, but in order to implement custom output formats, users need to reimplement everything.
If the FileInfo members were protected instead of private, they'd be able to reuse the code.

Reviewers: bogner, davide, scott.smith

Subscribers: llvm-commits

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

llvm-svn: 338013

[clangd] Do not rebuild AST if inputs have not changed

Summary:
If the contents are the same, the update most likely comes from the
fact that compile commands were invalidated. In that case we want to
avoid rebuilds in case the compile commands are actually the same.

Reviewers: ioeric

Reviewed By: ioeric

Subscribers: simark, javed.absar, MaskRay, jkorous, arphaman, jfb, cfe-commits

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

llvm-svn: 338012

[AArch64][NFC] Removed tab characters from test files.

llvm-svn: 338011

[AArch64] Armv8.2-A: add the crypto extensions

This adds MC support for the crypto instructions that were made optional
extensions in Armv8.2-A (AArch64 only).

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

llvm-svn: 338010

[ConstProp] Fix calls-math-finite.ll on FreeBSD

FreeBSD's log(3.0) is less precise than glibc and musl.
Let's forgive its rounding error of more than half an ulp.

llvm-svn: 338009

[AsmParser] Fix preserve-comments-crlf.s on FreeBSD

--strip-trailing-cr is a diffutils option which is also available on
BSD-licensed diff introduced in FreeBSD 11.2, however, it has a bug
comparing files mixing \r and \r\n. Use -b (POSIX) instead.

llvm-svn: 338008

[X86] Don't use CombineTo to skip adding new nodes to the DAGCombiner worklist in combineMul.

I'm not sure if this was trying to avoid optimizing the new nodes further or what. Or maybe to prevent a cycle if something tried to reform the multiply? But I don't think its a reliable way to do that. If the user of the expanded multiply is visited by the DAGCombiner after this conversion happens, the DAGCombiner will check its operands, see that they haven't been visited by the DAGCombiner before and it will then add the first node to the worklist. This process will repeat until all the new nodes are visited.

So this seems like an unreliable prevention at best. So this patch just returns the new nodes like any other combine. If this starts causing problems we can try to add target specific nodes or something to more directly prevent optimizations.

Now that we handle the combine normally, we can combine any negates the mul expansion creates into their users since those will be visited now.

llvm-svn: 338007

[CMake] Don't generate linker script only when shared library isn't statically linked

Since r337668, we support statically linking dependencies only to shared
or static library. However, that change hasn't updated the check whether
to generate a linker script. We shouldn't generate linker script only in
the case when we aren't statically linked ABI into the shared library.

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

llvm-svn: 338006

Copy LLVM CMake configuration for CMake Policy CMP0068

llvm-svn: 338005

[sanitizer] Include signal.h instead of sys/signal.h

llvm-svn: 338004

[Docs] Update of Xray page

Update of supported oses.

Reviewers: dberris

Reviewed By: dberris

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

llvm-svn: 338003

Be more consistent about which bool value means an error occurred

llvm-svn: 338002

Cleanup the last_write_time internals

llvm-svn: 338001

Correct comment about stat truncating st_mtimespec to seconds

llvm-svn: 338000

Fix attribute placement WRT extern C

llvm-svn: 337999

Workaround OS X 10.11 behavior where stat truncates st_mtimespec to seconds.

llvm-svn: 337998

Revert r337981: it breaks the debuginfo-tests

This commit caused a regression in the debuginfo-tests:

FAIL: debuginfo-tests :: apple-accel.cpp (40748 of 46595)
llvm-svn: 337997

[X86] Remove some unnecessary explicit calls to DCI.AddToWorkList.

These calls were making sure some newly created nodes were added to worklist, but the DAGCombiner has internal support for ensuring it has visited all nodes. Any time it visits a node it ensures the operands have been queued to be visited as well. This means if we only need to return the last new node. The DAGCombiner will take care of adding its inputs thus walking backwards through all the new nodes.

llvm-svn: 337996

[Support] Introduce createStringError helper function

The function in question is copy-pasted lots of times in DWARF-related classes.
Thus it will make sense to place its implementation into the Support library.

Reviewed by: lhames

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

llvm-svn: 337995

[GlobalISel] Fall back to SDISel for swifterror/swiftself attributes.

We don't currently support these, fall back until we do.

llvm-svn: 337994

[DWARF v5] Don't report an error when the .debug_rnglists section is empty or non-existent. Fixes PR38297.

Reviewer: JDevlieghere

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

llvm-svn: 337993

[LoadStoreVectorizer] Use const reference

llvm-svn: 337992

Add print statements to help debugging

llvm-svn: 337991

[libc++] Add hack to allow ubsan to work w/o compiler-rt (__muloti4 is undefined)

Summary:
Using int128_t with UBSAN causes link errors unless compiler-rt is providing the runtime library.
Specifically ubsan generates calls to __muloti4 but libgcc doesn't provide a definition.

In order to avoid this, and allow users to continue using sanitized versions of libc++, this patch introduces a hack.
It adds a cribbed version of  the compiler-rt builtin to the libc++ filesystem sources.

I don't think this approach will work in the long run, but it seems OK for now.

Also see:

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

Reviewers: mclow.lists, ldionne, rsmith, jyknight, echristo

Reviewed By: echristo

Subscribers: dberris, cfe-commits

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

llvm-svn: 337990

RegUsageInfo: Cleanup; NFC

- Remove unnecessary anchor function
- Remove unnecessary override of getAnalysisUsage
- Use reference instead of pointers where things cannot be nullptr
- Use ArrayRef instead of std::vector where possible

llvm-svn: 337989

CodeGen.cpp: Sort initializers; NFC

llvm-svn: 337988

InitializePasses: Sort declarations; NFC

llvm-svn: 337987

CodeGen: Cleanup regmask construction; NFC

- Avoid duplication of regmask size calculation.
- Simplify allocateRegisterMask() call.
- Rename allocateRegisterMask() to allocateRegMask() to be consistent
  with naming in MachineOperand.

llvm-svn: 337986

[MCA] Avoid an InstrDesc copy in mca::LSUnit::reserve.

Summary:
InstrDesc contains 4 vectors (as well as some other data), so it's
expensive to copy.

Authored By: orodley

Reviewers: andreadb, mattd, dberris

Reviewed By: mattd, dberris

Subscribers: dberris, gbedwell, llvm-commits

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

llvm-svn: 337985

[libc++] Follow-up to r337968: use an explicit cast as suggested by Eric

llvm-svn: 337984

[ELF] Fix linker-script-in-search-path.s

llvm-svn: 337983

[CMake] Don't use LIBCXXABI_ENABLE_STATIC option before its declared

Summary:
rL337867 introduced two new cmake_dependent_option options:
- LIBCXXABI_INSTALL_STATIC_LIBRARY
- LIBCXXABI_INSTALL_SHARED_LIBRARY

They depend on LIBCXXABI_ENABLE_STATIC and LIBCXXABI_ENABLE_SHARED
and so therefore need to (it seems) come after the declaration of
these two options.

Subscribers: mgorny, aheejin, christof, ldionne, cfe-commits

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

llvm-svn: 337982

[DWARF v5] Don't emit multiple DW_AT_rnglists_base attributes. Some refactoring of
range lists emissions and added test cases.

Reviewer: dblaikie

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

llvm-svn: 337981

[dsymutil] Add support for generating DWARF5 accelerator tables.

This patch add support for emitting DWARF5 accelerator tables
(.debug_names) from dsymutil. Just as with the Apple style accelerator
tables, it's possible to update existing dSYMs. This patch includes a
test that show how you can convert back and forth between the two types.

If no kind of table is specified, dsymutil will default to generating
Apple-style accelerator tables whenever it finds those in its input. The
same is true when there are no accelerator tables at all. Finally, in
the remaining case, where there's at least one DWARF v5 table and no
Apple ones, the output will contains a DWARF accelerator tables
(.debug_names).

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

llvm-svn: 337980

[CMake] Don't install c++abi headers in standalone libc++ build

This is a refinement on r337833. Previously we were installing two
copies of c++abi headers in libc++ build directory, one in
include/c++build and another one in include/c++/v1. However, the
second copy is unnecessary when building libc++ standalone.

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

llvm-svn: 337979

[ODRHash] Support hashing enums.

llvm-svn: 337978

bpf: new option -bpf-expand-memcpy-in-order to expand memcpy in order

Some BPF JIT backends would want to optimize memcpy in their own
architecture specific way.

However, at the moment, there is no way for JIT backends to see memcpy
semantics in a reliable way. This is due to LLVM BPF backend is expanding
memcpy into load/store sequences and could possibly schedule them apart from
each other further. So, BPF JIT backends inside kernel can't reliably
recognize memcpy semantics by peephole BPF sequence.

This patch introduce new intrinsic expand infrastructure to memcpy.

To get stable in-order load/store sequence from memcpy, we first lower
memcpy into BPF::MEMCPY node which then expanded into in-order load/store
sequences in expandPostRAPseudo pass which will happen after instruction
scheduling. By this way, kernel JIT backends could reliably recognize
memcpy through scanning BPF sequence.

This new memcpy expand infrastructure is gated by a new option:

  -bpf-expand-memcpy-in-order

Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 337977

Work around GCC bug in constexpr function

llvm-svn: 337976

[ELF] Make linker-script-in-search-path.s robust per r337972

llvm-svn: 337975

Fix GCC build in C++14 w/o c++14 constexpr

llvm-svn: 337974

[GlobalMerge] Handle llvm.compiler.used correctly.

Reuse the handling for llvm.used, and don't transform such globals.

Fixes a failure on the asan buildbot caused by my previous commit.

llvm-svn: 337973

Make a test more robust.

Previously, this test fails if there's other test that happens to
create "t.script" in the current directory.

llvm-svn: 337972

Remove test which shouldn't have been committed

llvm-svn: 337971

Fix failing test under C++14

llvm-svn: 337970

[ELF] Use search paths for --version-script=

Summary: This behavior matches ld.bfd -Ld --version-script=t.script a.o

Reviewers: ruiu, espindola

Subscribers: emaste, arichardson, llvm-commits

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

llvm-svn: 337969

[libc++] Follow-up to r337960: specify lambda's return type to avoid
-Wc++11-narrowing warning on Darwin

The internal CI produced the following diagnostic:
error: non-constant-expression cannot be narrowed from type 'long long' to '__darwin_suseconds_t' (aka 'int') in initializer list [-Wc++11-narrowing]
  struct ::timeval ConvertedTS[2] = {{TS[0].tv_sec, Convert(TS[0].tv_nsec)},
                                                    ^~~~~~~~~~~~~~~~~~~~~~

llvm-svn: 337968

ELF: Do not ICF SHF_LINK_ORDER sections.

We are already ICF'ing these sections as a unit with their dependent
sections, so they don't need to be considered for ICF individually.

This change also "fixes" slowness caused by our quadratic-in-group-size
relocation segregation algorithm on 32-bit ARM platforms with unwind
data and ICF on rodata. In this scenario almost every function's
.ARM.exidx is identical except for the targets of the relocations
that refer to the function and its .ARM.extab, which causes almost
all of the program's .ARM.exidx sections to be initially added to the
same class, which causes us to compare every such section with every
other such section.

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

llvm-svn: 337967

[SelectionDAG] try to convert funnel shift directly to rotate if legal

If the DAGCombiner's rotate matching was working as expected,
I don't think we'd see any test diffs here.

This sidesteps the issue of custom lowering for rotates raised in PR38243:
https://bugs.llvm.org/show_bug.cgi?id=38243
...by only dealing with legal operations.

llvm-svn: 337966

[LSV] Look through selects for consecutive addresses

In some cases LSV sees (load/store _ (select _ <pointer expression>
<pointer expression>)) patterns in input IR, often due to sinking and
other forms of CFG simplification, sometimes interspersed with
bitcasts and all-constant-indices GEPs. With this
patch`areConsecutivePointers` method would attempt to handle select
instructions. This leads to an increased number of successful
vectorizations.

Technically, select instructions could appear in index arithmetic as
well, however, we don't see those in our test suites / benchmarks.
Also, there is a lot more freedom in IR shapes computing integral
indices in general than in what's common in pointer computations, and
it appears that it's quite unreliable to do anything short of making
select instructions first class citizens of Scalar Evolution, which
for the purposes of this patch is most definitely an overkill.

Reviewed By: rampitec

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

llvm-svn: 337965

[AArch, PowerPC] add more tests for legal rotate ops; NFC

llvm-svn: 337964

Revert "[DataFormatters] Add formatter for C++17 std::optional."

I forgot to git add some files. I'm going to recommit the correct
version at once soon.

llvm-svn: 337963

Make <experimental/filesystem> compile with gcc 4.8.5

Patch by Victor Zverovich.

This fixes an error when compiling `<experimental/filesystem>` with gcc 4.8.5:

```
.../libcxx/src/experimental/filesystem/filesystem_common.h:137:34:
error: redeclaration ‘T
std::experimental::filesystem::v1::detail::{anonymous}::error_value() [with T =
bool]’ d
iffers in ‘constexpr’
 constexpr bool error_value<bool>() {
                                  ^
.../libcxx/src/experimental/filesystem/filesystem_common.h:133:3:
error: from previous declaration ‘T
std::experimental::filesystem::v1::detail::{anonymous}::error_value() [with T
 = bool]’
 T error_value();
   ^
```

Reviewed as https://reviews.llvm.org/D49813

llvm-svn: 337962

[GlobalMerge] Allow merging globals with arbitrary alignment.

Instead of depending on implicit padding from the structure layout code,
use a packed struct and emit the padding explicitly.

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

llvm-svn: 337961

[libc++] Use __int128_t to represent file_time_type.

Summary:
The ``file_time_type`` time point is used to represent the write times for files.
Its job is to act as part of a C++ wrapper for less ideal system interfaces. The
underlying filesystem uses the ``timespec`` struct for the same purpose.

However, the initial implementation of ``file_time_type`` could not represent
either the range or resolution of ``timespec``, making it unsuitable. Fixing
this requires an implementation which uses more than 64 bits to store the
time point.

I primarily considered two solutions: Using ``__int128_t`` and using a
arithmetic emulation of ``timespec``. Each has its pros and cons, and both
come with more than one complication.

However, after a lot of consideration, I decided on using `__int128_t`. This patch implements that change.

Please see the [FileTimeType Design Document](http://libcxx.llvm.org/docs/DesignDocs/FileTimeType.html) for more information.

Reviewers: mclow.lists, ldionne, joerg, arthur.j.odwyer, EricWF

Reviewed By: EricWF

Subscribers: christof, K-ballo, cfe-commits, BillyONeal

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

llvm-svn: 337960

[DataFormatters] Add formatter for C++17 std::optional.

<rdar://problem/41471112>

Patch by Shafik Yaghmour.

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

llvm-svn: 337959

[OPENMP] ThreadId in serialized parallel regions is 0.

The first argument for the parallel outlined functions, called as
serialized parallel regions, should be a pointer to the global thread id
that always is 0.

llvm-svn: 337957

Revert r337904: [IPSCCP] Use PredicateInfo to propagate facts from cmp instructions.

I suspect it is causing the clang-stage2-Rthinlto failures.

llvm-svn: 337956

[libc++] Factor duplicate code into function templates

Summary:
The exact same code was replicated 11 times for implementing the basic_istream
input operators (those that don't use numeric_limits). The same code was also
duplicated twice for implementing the basic_istream input operators that take
numeric_limits into account.

This commit factors the common code into function templates to avoid
the duplication.

Reviewers: mclow.lists, EricWF

Subscribers: christof, dexonsmith, cfe-commits

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

llvm-svn: 337955

[analyzer] Update SMT API documentation and methods

Summary:
Update the documentation of all the classes introduced with the new generic SMT API, most of them were referencing Z3 and how previous operations were being done (like including the context as parameter in a few methods).

Renamed the following methods, so it's clear that the operate on bitvectors:
*`mkSignExt` -> `mkBVSignExt`
*`mkZeroExt` -> `mkBVZeroExt`
*`mkExtract` -> `mkBVExtract`
*`mkConcat` -> `mkBVConcat`

Removed the unecessary methods:
* `getDataExpr`: it was an one line method that called `fromData`
* `mkBitvector(const llvm::APSInt Int)`: it was not being used anywhere

Reviewers: NoQ, george.karpenkov

Reviewed By: george.karpenkov

Subscribers: xazax.hun, szepet, a.sidorin

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

llvm-svn: 337954

[Preprocessor] Stop entering included files after hitting a fatal error.

Fixes a problem when we have multiple inclusion cycles and try to
enumerate all possible ways to reach the max inclusion depth.

rdar://problem/38871876

Reviewers: bruno, rsmith, jkorous, aaron.ballman

Reviewed By: bruno, jkorous, aaron.ballman

Subscribers: dexonsmith, cfe-commits

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

llvm-svn: 337953

Add missing 'override', fixing compilation with some compilers since SVN r337950

llvm-svn: 337952

[COFF] Use comdat shared constants for MinGW as well

GNU binutils tools have no problems with this kind of shared constants,
provided that we actually hook it up completely in AsmPrinter and
produce a global symbol.

This effectively reverts SVN r335918 by hooking the rest of it up
properly.

This feature was implemented originally in SVN r213006, with no reason
for why it can't be used for MinGW other than the fact that GCC doesn't
do it while MSVC does.

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

llvm-svn: 337951

[COFF] Hoist constant pool handling from X86AsmPrinter into AsmPrinter

In SVN r334523, the first half of comdat constant pool handling was
hoisted from X86WindowsTargetObjectFile (which despite the name only
was used for msvc targets) into the arch independent
TargetLoweringObjectFileCOFF, but the other half of the handling was
left behind in X86AsmPrinter::GetCPISymbol.

With only half of the handling in place, inconsistent comdat
sections/symbols are created, causing issues with both GNU binutils
(avoided for X86 in SVN r335918) and with the MS linker, which
would complain like this:

fatal error LNK1143: invalid or corrupt file: no symbol for COMDAT section 0x4

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

llvm-svn: 337950

[libFuzzer] Disable handle-unstable.test for ARM and delete duplicated test file.

Summary:
This change should fix the failures mentioned in
https://reviews.llvm.org/D49684#1175245

Reviewers: kevinwkt, morehouse, metzman

Reviewed By: kevinwkt, morehouse

Subscribers: kristof.beyls, delcypher, chrib, #sanitizers, llvm-commits, kcc

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

llvm-svn: 337949

[analyzer] Fix compilation when LLVM_ENABLE_MODULES=ON

llvm-svn: 337948

[LangRef] Clarify undefined behavior for function attributes.

Violating the invariants specified by attributes is undefined behavior.
Maybe we could use poison instead for some of the parameter attributes,
but I don't think it's worthwhile.

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

llvm-svn: 337947

[windows] Fix warning about comparing ints of different signs

This fixes a warning like this:

warning: comparison of integers of different signs:
      'std::__1::__libcpp_tls_key' (aka 'long') and 'DWORD'
      (aka 'unsigned long') [-Wsign-compare]
  if (*__key == FLS_OUT_OF_INDEXES)
      ~~~~~~ ^  ~~~~~~~~~~~~~~~~~~

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

llvm-svn: 337946

[ARM] Prefer lsls+lsrs over lsls+ands or lsrs+ands in Thumb1.

Saves materializing the immediate for the "ands".

Corresponding patterns exist for lsrs+lsls, but that seems less common
in practice.

Now implemented as a DAGCombine.

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

llvm-svn: 337945

[clang:sema] de-duplicate getDepthAndIndex helpers

Summary:
Continuing off of:
https://reviews.llvm.org/D38382

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

Reviewers: srhines, pirama, vsk

Reviewed By: vsk

Subscribers: cfe-commits, vsk, maitesin

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

llvm-svn: 337944

[SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform

as well as sext(C + x + ...) -> (D + sext(C-D + x + ...))<nuw><nsw>
similar to the equivalent transformation for zext's

if the top level addition in (D + (C-D + x * n)) could be proven to
not wrap, where the choice of D also maximizes the number of trailing
zeroes of (C-D + x * n), ensuring homogeneous behaviour of the
transformation and better canonicalization of such AddRec's

(indeed, there are 2^(2w) different expressions in `B1 + ext(B2 + Y)` form for
the same Y, but only 2^(2w - k) different expressions in the resulting `B3 +
ext((B4 * 2^k) + Y)` form, where w is the bit width of the integral type)

This patch generalizes sext(C1 + C2*X) --> sext(C1) + sext(C2*X) and
sext{C1,+,C2} --> sext(C1) + sext{0,+,C2} transformations added in
r209568 relaxing the requirements the following way:

1. C2 doesn't have to be a power of 2, it's enough if it's divisible by 2
 a sufficient number of times;
2. C1 doesn't have to be less than C2, instead of extracting the entire
  C1 we can split it into 2 terms: (00...0XXX + YY...Y000), keep the
  second one that may cause wrapping within the extension operator, and
  move the first one that doesn't affect wrapping out of the extension
  operator, enabling further simplifications;
3. C1 and C2 don't have to be positive, splitting C1 like shown above
 produces a sum that is guaranteed to not wrap, signed or unsigned;
4. in AddExpr case there could be more than 2 terms, and in case of
  AddExpr the 2nd and following terms and in case of AddRecExpr the
  Step component don't have to be in the C2*X form or constant
  (respectively), they just need to have enough trailing zeros,
  which in turn could be guaranteed by means other than arithmetics,
  e.g. by a pointer alignment;
5. the extension operator doesn't have to be a sext, the same
  transformation works and profitable for zext's as well.

Apparently, optimizations like SLPVectorizer currently fail to
vectorize even rather trivial cases like the following:

 double bar(double *a, unsigned n) {
   double x = 0.0;
   double y = 0.0;
   for (unsigned i = 0; i < n; i += 2) {
     x += a[i];
     y += a[i + 1];
   }
   return x * y;
 }

If compiled with `clang -std=c11 -Wpedantic -Wall -O3 main.c -S -o - -emit-llvm`
(!{!"clang version 7.0.0 (trunk 337339) (llvm/trunk 337344)"})

it produces scalar code with the loop not unrolled with the unsigned `n` and
`i` (like shown above), but vectorized and unrolled loop with signed `n` and
`i`. With the changes made in this commit the unsigned version will be
vectorized (though not unrolled for unclear reasons).

How it all works:

Let say we have an AddExpr that looks like (C + x + y + ...), where C
is a constant and x, y, ... are arbitrary SCEVs. Let's compute the
minimum number of trailing zeroes guaranteed of that sum w/o the
constant term: (x + y + ...). If, for example, those terms look like
follows:

        i
XXXX...X000
YYYY...YY00
   ...
ZZZZ...0000

then the rightmost non-guaranteed-zero bit (a potential one at i-th
position above) can change the bits of the sum to the left (and at
i-th position itself), but it can not possibly change the bits to the
right. So we can compute the number of trailing zeroes by taking a
minimum between the numbers of trailing zeroes of the terms.

Now let's say that our original sum with the constant is effectively
just C + X, where X = x + y + .... Let's also say that we've got 2
guaranteed trailing zeros for X:

         j
CCCC...CCCC
XXXX...XX00  // this is X = (x + y + ...)

Any bit of C to the left of j may in the end cause the C + X sum to
wrap, but the rightmost 2 bits of C (at positions j and j - 1) do not
affect wrapping in any way. If the upper bits cause a wrap, it will be
a wrap regardless of the values of the 2 least significant bits of C.
If the upper bits do not cause a wrap, it won't be a wrap regardless
of the values of the 2 bits on the right (again).

So let's split C to 2 constants like follows:

0000...00CC  = D
CCCC...CC00  = (C - D)

and represent the whole sum as D + (C - D + X). The second term of
this new sum looks like this:

CCCC...CC00
XXXX...XX00
-----------  // let's add them up
YYYY...YY00

The sum above (let's call it Y)) may or may not wrap, we don't know,
so we need to keep it under a sext/zext. Adding D to that sum though
will never wrap, signed or unsigned, if performed on the original bit
width or the extended one, because all that that final add does is
setting the 2 least significant bits of Y to the bits of D:

YYYY...YY00 = Y
0000...00CC = D
-----------  <nuw><nsw>
YYYY...YYCC

Which means we can safely move that D out of the sext or zext and
claim that the top-level sum neither sign wraps nor unsigned wraps.

Let's run an example, let's say we're working in i8's and the original
expression (zext's or sext's operand) is 21 + 12x + 8y. So it goes
like this:

0001 0101  // 21
XXXX XX00  // 12x
YYYY Y000  // 8y

0001 0101  // 21
ZZZZ ZZ00  // 12x + 8y

0000 0001  // D
0001 0100  // 21 - D = 20
ZZZZ ZZ00  // 12x + 8y

0000 0001  // D
WWWW WW00  // 21 - D + 12x + 8y = 20 + 12x + 8y

therefore zext(21 + 12x + 8y) = (1 + zext(20 + 12x + 8y))<nuw><nsw>

This approach could be improved if we move away from using trailing
zeroes and use KnownBits instead. For instance, with KnownBits we could
have the following picture:

    i
10 1110...0011  // this is C
XX X1XX...XX00  // this is X = (x + y + ...)

Notice that some of the bits of X are known ones, also notice that
known bits of X are interspersed with unknown bits and not grouped on
the rigth or left.

We can see at the position i that C(i) and X(i) are both known ones,
therefore the (i + 1)th carry bit is guaranteed to be 1 regardless of
the bits of C to the right of i. For instance, the C(i - 1) bit only
affects the bits of the sum at positions i - 1 and i, and does not
influence if the sum is going to wrap or not. Therefore we could split
the constant C the following way:

    i
00 0010...0011  = D
10 1100...0000  = (C - D)

Let's compute the KnownBits of (C - D) + X:

XX1 1            = carry bit, blanks stand for known zeroes
 10 1100...0000  = (C - D)
 XX X1XX...XX00  = X
--- -----------
 XX X0XX...XX00

Will this add wrap or not essentially depends on bits of X. Adding D
to this sum, however, is guaranteed to not to wrap:

0    X
 00 0010...0011  = D
 sX X0XX...XX00  = (C - D) + X
--- -----------
 sX XXXX   XX11

As could be seen above, adding D preserves the sign bit of (C - D) +
X, if any, and has a guaranteed 0 carry out, as expected.

The more bits of (C - D) we constrain, the better the transformations
introduced here canonicalize expressions as it leaves less freedom to
what values the constant part of ((C - D) + x + y + ...) can take.

Reviewed By: mzolotukhin, efriedma

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

llvm-svn: 337943