Improve the documentation for OpenCL vector types.

This fixes some minor grammatical issues I noticed when reading the docs, and changes the recommended feature testing approach to use __has_attribute instead of __has_extension.

llvm-svn: 369687

Fix the nullPointerConstant() test to get bots back to green.

llvm-svn: 369686

[AArch64] autogenerate some tests. NFC

llvm-svn: 369685

[heap.py] Add missing declaration for malloc_get_all_zones

The evaluation context isn't guaranteed to have this declaration.

Fixes "error: use of undeclared identifier 'malloc_get_all_zones'" bugs.

llvm-svn: 369684

Implement nullPointerConstant() using a better API.

Instead of manually attempting to identify whether something is a null pointer constant, use Expr::isNullPointerConstant().

llvm-svn: 369683

gn build: Merge r369680

llvm-svn: 369682

Introduce FileEntryRef and use it when handling includes to report correct dependencies
when the FileManager is reused across invocations

This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns
a reference to the FileEntry, and the name that was used to access the file. In the case of
a VFS with 'use-external-names', the FileEntyRef contains the external name of the file,
not the filename that was used to access it.

The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the
accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using
the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file
is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations.

Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies
are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits.

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

llvm-svn: 369680

[clangd] Fold string copy into lambda capture. NFC.

llvm-svn: 369679

gn build: Merge r369677

llvm-svn: 369678

Revert "[LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)"

This reverts commit r369591, because it causes the formerly-reliable
-Wreturn-stack-address warning to start issuing false positives.
Testcase provided on the commit thread.

llvm-svn: 369677

[Clangd] Tweaktesting replace toString with consumeError

llvm-svn: 369676

Retire llvm::less_ptr. llvm::deref is much more flexible.

llvm-svn: 369675

Retire llvm::less/equal in favor of C++14 std::less<>/equal_to<>.

llvm-svn: 369674

GlobalISel: Don't create G_UADDE with constant false carry in

The x86 tests are now broken (in paticular add-scalar.ll now hits the
DAG fallback) due to not handling G_UADDO. The DAG x86 backend has a
custom lowering for this, so that will need to be implemented.

llvm-svn: 369673

[libc++] Mark lock_guard nodiscard test as unsupported in C++03

llvm-svn: 369672

[MachO][TLOF] Use hasLocalLinkage to determine if indirect symbol is local

Local symbols in the indirect symbol table contain the value
`INDIRECT_SYMBOL_LOCAL` and the corresponding __pointers entry must
contain the address of the target.

In r349060, I added support for local symbols in the indirect symbol
table, which was checking if the symbol `isDefined` && `!isExternal` to
determine if the symbol is local or not.

It turns out that `isDefined` will return false if the user of the
symbol comes before its definition, and we'll again generate .long 0
which will be the symbol at the adress 0x0.

Instead of doing that, use GlobalValue::hasLocalLinkage() to check if
the symbol is local.

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

llvm-svn: 369671

Remove redundant curly braces.

llvm-svn: 369670

Doxygenify comments.

llvm-svn: 369669

[OPENMP]Generalization of handling of declare target attribute.

Used OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration instead of
direct checking of the OMPDeclareTargetDeclAttr attribute.

llvm-svn: 369668

[NFC][InstCombine] New tests: unrecognized_three-way-comparison.ll is ignorant about commutative variants

D66232 "exposes" the problem.

llvm-svn: 369667

Fixed Missing Expected error handling

llvm-svn: 369666

[X86] Remove MCInstLower code that drops operands from some CALL and TAILJMP instructions. Add asserts to verify operand count

It appears the FIXME here was handled at some point. r159728 from 2012 seems to be at least aportion of fixing it.

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

llvm-svn: 369665

[MBP] Disable aggressive loop rotate in plain mode

Patch https://reviews.llvm.org/D43256 introduced more aggressive loop layout optimization which depends on profile information. If profile information is not available, the statically estimated profile information(generated by BranchProbabilityInfo.cpp) is used. If user program doesn't behave as BranchProbabilityInfo.cpp expected, the layout may be worse.

To be conservative this patch restores the original layout algorithm in plain mode. But user can still try the aggressive layout optimization with -force-precise-rotation-cost=true.

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

llvm-svn: 369664

[DAGCombiner] Remove explicit call to AddToWorklist in sqrt and reciprocal computations

Summary: These nodes end up being processed regardless due to DAGCombiner ensuring arguments are processed. This changes the order in which nodes are processed, which fixes an issue on PowerPC.

Reviewers: craig.topper, efriedma, RKSimon, lebedev.ri, mcberg2017, stefanp, hfinkel

Subscribers: nemanjai, MaskRay, jsji, steven.zhang, llvm-commits

Tags: #llvm

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

llvm-svn: 369662

[X86][BtVer2] Fix latency/throughput of scalar integer MUL instructions.

Single operand MUL instructions that implicitly set EAX have the following
latency/throughput profile (see below):

imul %cl              # latency: 3cy - uOPs: 1 - 1 JMul
imul %cx              # latency: 3cy - uOPs: 3 - 3 JMul
imul %ecx             # latency: 3cy - uOPs: 2 - 2 JMul
imul %rcx             # latency: 6cy - uOPs: 2 - 4 JMul

mul %cl               # latency: 3cy - uOPs: 1 - 1 JMul
mul %cx               # latency: 3cy - uOPs: 3 - 3 JMul
mul %ecx              # latency: 3cy - uOPs: 2 - 2 JMul
mul %rcx              # latency: 6cy - uOPs: 2 - 4 JMul

Excluding the 64bit variant, which has a latency of 6cy, every other instruction
has a latency of 3cy. However, the number of decoded macro-opcodes (as well as
the resource cyles) depend on the MUL size.

The two operand MULs have a more predictable profile (see below):

imul %dx, %dx         # latency: 3cy - uOPs: 1 - 1 JMul
imul %edx, %edx       # latency: 3cy - uOPs: 1 - 1 JMul
imul %rdx, %rdx       # latency: 6cy - uOPs: 1 - 4 JMul

imul $3, %dx, %dx     # latency: 4cy - uOPs: 2 - 2 JMul
imul $3, %ecx, %ecx   # latency: 3cy - uOPs: 1 - 1 JMul
imul $3, %rdx, %rdx   # latency: 6cy - uOPs: 1 - 4 JMul

This patch updates the values in the Jaguar scheduling model and regenerates
llvm-mca tests.

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

llvm-svn: 369661

[lldb] Remove ')' to fix the build

That ')' slipped in by accident in the reformatting commit.

llvm-svn: 369660

[PowerPC] Regenerate reciprocal tests, as discussed on D66548

llvm-svn: 369659

[PowerPC] Add combined ELF ABI and 32/64 bit queries to the subtarget. [NFC]

A lot of places in the code combine checks for both ABI (SVR4/Darwin/AIX) and
addressing mode (64-bit vs 32-bit). In an attempt to make some of the code more
readable I've added a couple functions that combine checking for the ELF abi and
64-bit/32-bit code at once. As we add more AIX support I intend to add similar
functions for the AIX ABI.

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

llvm-svn: 369658

[PowerPC][XCOFF][MC] Explicitly set containing csect on symbols. [NFC]

Previously we would get the csect a symbol was contained in through its
fragment. This works only if we are writing an object file, and only for
defined symbols. To fix this we set the contating csect explicitly on the
MCSymbolXCOFF object.

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

llvm-svn: 369657

[clangd] Send suppported codeActionKinds to the client.

Summary:
This would make client know which codeActionKinds that clangd may
return.

VSCode will add a new entry "Refactor..." (which shows all
refactoring-kind code actions) in the right-click menu.

Reviewers: ilya-biryukov

Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 369656

[lldb] Fix `TestDataFormatterStdList` regression

Since D66174 I see failures of TestDataFormatterStdList in about 50% of runs on
Fedora 30 x86_64 libstdc++. I have found out that LLDB internally expects these
RegularExpressions to be matched in their alphabetical order:
^std::(__cxx11::)?list<.+>(( )?&)?$
^std::__[[:alnum:]]+::list<.+>(( )?&)?$

But since D66174 they are sometimes matched in reverse order. In fact it was
only some luck it worked before as there is internally
std::map<lldb::RegularExpressionSP, FormatterImpl> (FormattersContainer).

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

llvm-svn: 369655

[Attributor][NFC] Move DerefState to header and use StateWrapper

Summary: In D65402, I want to get DerefState from AADereferenceable but it was not allowed. This patch moves DerefState definition into Attributor.h and makes AADerefenceable inherit StateWrapper.

Reviewers: jdoerfert, sstefan1

Reviewed By: jdoerfert

Subscribers: hiraditya, jfb, llvm-commits

Tags: #llvm

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

llvm-svn: 369653

[lldb][NFC] Fix indentation in CommandObjectProcess

llvm-svn: 369652

[SlotIndexes] Add print-slotindexes to disable printing slotindexes

Summary:
When we print the IR with --print-after/before-*,
SlotIndexes will be printed whenever available (We haven't freed it).

This introduces some noises when we try to compare the IR
among different optimizations.

eg:
-print-before=machine-cp will print SlotIndexes for 1st machine-cp
pass, but NOT for 2nd machine-cp;
-print-after=machine-cp will NOT print SlotIndexes for both
machine-cp passes.
So SlotIndexes in 1st pass introduce noises when differing these IRs.

This patch introduces an option to hide indexes.

Reviewers: stoklund, thegameg, qcolombet

Reviewed By: thegameg

Subscribers: hiraditya, arphaman, llvm-commits

Tags: #llvm

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

llvm-svn: 369650

[MCA] consistently use MCPhysReg instead of unsigned as register type. NFCI

llvm-svn: 369648

Revert r369402 "win: Enable /Zc:twoPhase by default if targeting MSVC 2017 update 3 or newer"

This broke compiling some ASan tests with never versions of MSVC/the Win
SDK, see https://crbug.com/996675

> MSVC 2017 update 3 (_MSC_VER 1911) enables /Zc:twoPhase by default, and
> so should clang-cl:
> https://docs.microsoft.com/en-us/cpp/build/reference/zc-twophase
>
> clang-cl takes the MSVC version it emulates from the -fmsc-version flag,
> or if that's not passed it tries to check what the installed version of
> MSVC is and uses that, and failing that it uses a default version that's
> currently 1911. So this changes the default if no -fmsc-version flag is
> passed and no installed MSVC is detected. (It also changes the default
> if -fmsc-version is passed or MSVC is detected, and either indicates
> _MSC_VER >= 1911.)
>
> As mentioned in the MSDN article, the Windows SDK header files in
> version 10.0.15063.0 (Creators Update or Redstone 2) and earlier
> versions do not work correctly with /Zc:twoPhase. If you need to use
> these old SDKs with a new clang-cl, explicitly pass /Zc:twoPhase- to get
> the old behavior.
>
> Fixes PR43032.
>
> Differential Revision: https://reviews.llvm.org/D66394

llvm-svn: 369647

[lldb][NFC] Add test for target stop-hook disable/enable/delete

llvm-svn: 369646

[yaml2obj] - Lookup relocation symbols in dynamic symbol when .dynsym referenced.

This fixes https://bugs.llvm.org/show_bug.cgi?id=40337.

Previously, it was always assumed that relocations referenced symbols in the static symbol table.
Now, if the Link field references a section called ".dynsym" it will look up these symbols
in the dynamic symbol table.

This patch is heavily based on D59097 by James Henderson

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

llvm-svn: 369645

Fix some regressions caused by r369553 on old versions of Debian and Ubuntu
It was causing some errors like:

Encoding error:
'ascii' codec can't decode byte 0xe2 in position 341: ordinal not in range(128)
The full traceback has been saved in /tmp/sphinx-err-y2fq4dtb.log, if you want to report the issue to the developers.

llvm-svn: 369644

Remove \brief commands from doxygen comments.

Summary:
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

  for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

[This is analogous to LLVM r331272 and CFE r331834]

Subscribers: srhines, nemanjai, javed.absar, kbarton, MaskRay, jkorous, arphaman, jfb, kadircet, jsji, cfe-commits

Tags: #clang

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

llvm-svn: 369643

[X86][BtVer2] Fix latency and throughput of XCHG and XADD.

On Jaguar, XCHG has a latency of 1cy and decodes to 2 macro-opcodes. Maximum
throughput for XCHG is 1 IPC. The byte exchange has worse latency and decodes to
1 extra uOP; maximum observed throughput is 0.5 IPC.

```
xchgb %cl, %dl           # Latency: 2cy  -  uOPs: 3  -  2 ALU
xchgw %cx, %dx           # Latency: 1cy  -  uOPs: 2  -  2 ALU
xchgl %ecx, %edx         # Latency: 1cy  -  uOPs: 2  -  2 ALU
xchgq %rcx, %rdx         # Latency: 1cy  -  uOPs: 2  -  2 ALU
```

The reg-mem forms of XCHG are atomic operations with an observed latency of
16cy.  The resource usage is similar to the XCHGrr variants. The biggest
difference is obviously the bus-locking, which prevents the LS to issue other
memory uOPs in parallel until the unlocking store uOP is executed.

```
xchgb %cl, (%rsp)        # Latency: 16cy  -  uOPs: 3 - ECX latency: 11cy
xchgw %cx, (%rsp)        # Latency: 16cy  -  uOPs: 3 - ECX latency: 11cy
xchgl %ecx, (%rsp)       # Latency: 16cy  -  uOPs: 3 - ECX latency: 11cy
xchgq %rcx, (%rsp)       # Latency: 16cy  -  uOPs: 3 - ECX latency: 11cy
```

The exchanged in/out register operand becomes available after 11cy from the
start of execution. Added test xchg.s to verify that we correctly see that
register write committed in 11cy (and not 16cy).

Reg-reg XADD instructions have the same latency/throughput than the byte
exchange (register-register variant).

```
xaddb %cl, %dl           # latency: 2cy  -  uOPs: 3  -  3 ALU
xaddw %cx, %dx           # latency: 2cy  -  uOPs: 3  -  3 ALU
xaddl %ecx, %edx         # latency: 2cy  -  uOPs: 3  -  3 ALU
xaddq %rcx, %rdx         # latency: 2cy  -  uOPs: 3  -  3 ALU
```

The non-atomic RM variants have a latency of 11cy, and decode to 4
macro-opcodes. They still consume 2 ALU pipes, and the exchange in/out register
operand becomes available in 3cy (it matches the 'load-to-use latency').

```
xaddb %cl, (%rsp)        # latency: 11cy  -  uOPs: 4  -  3 ALU
xaddw %cx, (%rsp)        # latency: 11cy  -  uOPs: 4  -  3 ALU
xaddl %ecx, (%rsp)       # latency: 11cy  -  uOPs: 4  -  3 ALU
xaddq %rcx, (%rsp)       # latency: 11cy  -  uOPs: 4  -  3 ALU
```

The atomic XADD variants execute in 16cy. The in/out register operand is
available after 11cy from the start of execution.

```
lock xaddb %cl, (%rsp)   # latency: 16cy - uOPs: 4 - 3 ALU -- ECX latency: 11cy
lock xaddw %cx, (%rsp)   # latency: 16cy - uOPs: 4 - 3 ALU -- ECX latency: 11cy
lock xaddl %ecx, (%rsp)  # latency: 16cy - uOPs: 4 - 3 ALU -- ECX latency: 11cy
lock xaddq %rcx, (%rsp)  # latency: 16cy - uOPs: 4 - 3 ALU -- ECX latency: 11cy
```

Added test xadd.s to verify those latencies as well as read-advance values.

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

llvm-svn: 369642

[OpenCL] Fix declaration of enqueue_marker

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

llvm-svn: 369641

[MVT] Add MVT equivalent to EVT::getHalfNumVectorElementsVT() helper. NFCI.

Allows for some cleanup in a lot of SSE/AVX vector splitting code

llvm-svn: 369640

Reapply: [ARM] Fix lsrl with a 128/256 bit shift amount or a shift of 32

The CodeGen/Thumb2/mve-vaddv.ll test needed to be amended to reflect the
changes from the above patch.

This reverts commit cd53ff6, reapplying 7c6b229.

llvm-svn: 369638

[Loop Peeling] Fix silly bug in metadata update.

We must update loop metedata before we moved to parent loop if
it is present.

llvm-svn: 369637

Revert r369626 "[ARM] Fix lsrl with a 128/256 bit shift amount or a shift of 32"

It broke the bots, see e.g. http://lab.llvm.org:8011/builders/clang-cuda-build/builds/36275/

> This patch fixes shifts by a 128/256 bit shift amount. It also fixes
> codegen for shifts of 32 by delegating to LLVM's default optimisation
> instead of emitting a long shift.
>
> Tests that used to generate long shifts of 32 are updated to check for the
> more optimised codegen.
>
> Differential revision: https://reviews.llvm.org/D66519
>
> llvm-svn: 369626

llvm-svn: 369636

[lldb][NFC] Remove unused return value from HandleOptionArgumentCompletion

llvm-svn: 369635

[llvm-objdump] - Remove an outdated "FIXME". NFC.

The bug mentioned in this test case was fixed in D63779 (r364955),
which also provides a test case.

llvm-svn: 369634

Revert r369458 "[DebugInfo] Add debug location to dynamic atexit destructor"

It causes the build to fail with

"inlinable function call in a function with debug info must have a !dbg location"

in Chromium. See llvm-commits thread for more info.

(This also reverts the follow-up in r369474.)

> Fixes PR43012
>
> Differential Revision: https://reviews.llvm.org/D66328

llvm-svn: 369633

[lldb][NFC] NFC cleanup for the completion code

llvm-svn: 369632

[clangd] The ClangdServer::EnableHiddenFeatures is not used any more.

Remove it.

llvm-svn: 369631

[llvm-readobj] - Remove `reportError(std::error_code EC, StringRef Input)` helper.

We do not need it, std::error_code is used mostly for COFF and
this patch rewrites the calls to use a different overload.

Having reportError(std::error_code EC, ... is excessive by itself,
because API that use error codes actually needs refactoring to
use Error/Expected<> instead.

DIfferential revision: https://reviews.llvm.org/D66521

llvm-svn: 369630

Remove an unused function, suppress -Wunused-function warning.

llvm-svn: 369629

[X86] Lower the cost of v2i32->v2f64 sint_to_fp under vector widening legalization.

I don't really understand the costs we're using for fp_to_sint,
but prior to widening legalization we used 20 as the cost for this
via the v2i64->v2f64 entry. That number seems better than the 40
we got with widening legalization. So now we need either a
v2i32->v2f64 entry or a v4i32->v2f64 entry depending on whether
AVX is enabled or not since we skip the first SSE2 table look up
under AVX.

llvm-svn: 369628

[Support] Improve readNativeFile(Slice) interface

Summary:
There was a subtle, but pretty important difference between the Slice
and regular versions of this function. The Slice function was
zero-initializing the rest of the buffer when the read syscall returned
less bytes than expected, while the regular function did not.

This patch removes the inconsistency by making both functions *not*
zero-initialize the buffer. The zeroing code is moved to the
MemoryBuffer class, which is currently the only user of this code. This
makes the API more consistent, and the code shorter.

While in there, I also refactor the functions to return the number of
bytes through the regular return value (via Expected<size_t>) instead of
a separate by-ref argument.

Reviewers: aganea, rnk

Subscribers: kristina, Bigcheese, llvm-commits

Tags: #llvm

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

llvm-svn: 369627

[ARM] Fix lsrl with a 128/256 bit shift amount or a shift of 32

This patch fixes shifts by a 128/256 bit shift amount. It also fixes
codegen for shifts of 32 by delegating to LLVM's default optimisation
instead of emitting a long shift.

Tests that used to generate long shifts of 32 are updated to check for the
more optimised codegen.

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

llvm-svn: 369626

[lldb][NFC] Remove dead code that is supposed to handle invalid command options

Summary:
We currently have a bunch of code that is supposed to handle invalid command options, but
all this code is unreachable because invalid options are already handled in `Options::Parse`.
The only way we can reach this code is when we declare but then not implement an option
(which will be made impossible with D65386, which is also when we can completely remove
the `default` cases).

This patch replaces all this code with `llvm_unreachable` to make clear this is dead code
that can't be reached.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 369625

[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values

Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:

* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.

I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.

A few words why those things should be removed/replaced:

* The return values are really cryptic, partly redundant and rarely documented.
  They are also completely ignored by Xcode, so whatever information they contain will end up
  breaking Xcode's completion mechanism. They are also partly impossible to even implement
  as we assign negative values special meaning and our completion API sometimes returns size_t.

  Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
  in some untested code path to expand the history repeat character to the full command, but
  I haven't figured out why that doesn't work at the moment.
  Completion functions return -1 to 'insert the completion character', but that isn't implemented
  (even though we seem to activate this feature in LLDB sometimes).
  All positive values have to match the number of results. This is obviously just redundant information
  as the user can just look at the result list to get that information (which is what Xcode does).

* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
  reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
  that we calculate this to make the life of the API caller easier, but obviously forcing people to have
  1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
  0-based like Xcode has to do).

* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
  idea is that we let the top-level API know that we just provided a full completion. Interestingly we
  `WordComplete` is just a single bool that somehow represents all N completions. And we always
  provide full completions in LLDB, so in theory it should always be true.
  The only use it currently serves is providing redundant information about whether we have a single
  definitive completion or not (which we already know from the number of results we get).

This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.

For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).

I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arphaman, abidh, lldb-commits

Tags: #lldb

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

llvm-svn: 369624

Revert "[GWP-ASan] Remove c++ standard lib dependency."

This reverts commit r369606: this doesn't addressed the underlying
problem and it's not the correct solution.

llvm-svn: 369623

[TargetLowering] Remove optional arguments passing to makeLibCall

The patch introduces MakeLibCallOptions struct as suggested by @efriedma on D65497.
The struct contain argument flags which will pass to makeLibCall function.
The patch should not has any functionality changes.

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

llvm-svn: 369622

[debugserver] Switch back to std::once_flag

We cannot use llvm::once_flag in debugserver because doesn't link
against llvm.

llvm-svn: 369621

[lit] Diagnose insufficient args to internal env

Without this patch, failing to provide a subcommand to lit's internal
`env` results in either a python `IndexError` or an attempt to execute
the final `env` argument, such as `FOO=1`, as a command.  This patch
diagnoses those cases with a more helpful message.

Reviewed By: stella.stamenova

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

llvm-svn: 369620

[OpenMP] Permit map with DSA on combined directive

For `map`, the following restriction changed in OpenMP 5.0:

* OpenMP 4.5 [2.15.5.1, Restrictions]: "A list item cannot appear in
  both a map clause and a data-sharing attribute clause on the same
  construct.

* OpenMP 5.0 [2.19.7.1, Restrictions]: "A list item cannot appear in
  both a map clause and a data-sharing attribute clause on the same
  construct unless the construct is a combined construct."

This patch removes this restriction in the case of combined constructs
and OpenMP 5.0, and it updates Sema not to capture a scalar by copy in
the target region when `firstprivate` and `map` appear for that scalar
on a combined target construct.

This patch also adds a fixme to a test that now reveals that a
diagnostic about loop iteration variables is dropped in the case of
OpenMP 5.0.  That bug exists regardless of this patch's changes.

Reviewed By: ABataev, jdoerfert, hfinkel, kkwli0

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

llvm-svn: 369619

[lldb] Replace std::once_flag with llvm::once_flag.

Summary:
The former seems like it's not working on some platforms.
All the other uses use `llvm::`, so, let's change for consistency.

Reviewers: jasonmolenda, friss

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 369618

[FormatManage] Fix the format info order

The format info entries need to match the order of the enum entries.
This should fix the two failing data-formatter tests.

llvm-svn: 369617

[analyzer] Enable control dependency condition tracking by default

This patch concludes my GSoC'19 project by enabling track-conditions by default.

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

llvm-svn: 369616

[analyzer] CastValueChecker: Model isa(), isa_and_nonnull()

Summary: -

Reviewed By: NoQ

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

llvm-svn: 369615

[FormatManager] Add static_assert to keep formats in sync.

This adds a static assert that ensures that there's a format info entry
for every format enum value. This should prevent others from making the
same mistake I made and Jason kindly fixed in r369611. (Thanks!)

llvm-svn: 369614

[analyzer] Don't track the condition of foreach loops

As discussed on the mailing list, notes originating from the tracking of foreach
loop conditions are always meaningless.

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

llvm-svn: 369613

[X86] Making X86OptimizeLEAs pass public. NFC

Reviewers: wxiao3, LuoYuanke, andrew.w.kaylor, craig.topper, annita.zhang, liutianle, pengfei, xiangzhangllvm, RKSimon, spatel, andreadb

Reviewed By: RKSimon

Subscribers: andreadb, hiraditya, llvm-commits

Tags: #llvm

Patch by Gen Pei (gpei)

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

llvm-svn: 369612

The g_format_infos table needs to be updated in concert with the
enum Format entries; else we can crash in a place like
FormatManager::GetFormatAsCString().  We should add  bounds checks
to prevent this more reliably, but for tonight I'm just adding this
entry to keep an address-sanitizer test run working.

llvm-svn: 369611

[COFF] Fix section name for constants larger than 64 bits on Windows

APIntToHexString returns wrong value ("0000000000000000ffffffffffffffff")
for integer larger than 64 bits, and thus
TargetLoweringObjectFileCOFF::getSectionForConstant returns same section name
for all numbers larger than 64 bits. This patch tries to fix it.

Differential Revision: https://reviews.llvm.org/D66458
Patch by Senran Zhang

llvm-svn: 369610

[analyzer] CastValueChecker: Try to fix the buildbots

llvm-svn: 369609

gn build: Merge r369605

llvm-svn: 369608

[analyzer] CastValueChecker: Rewrite dead header hotfix

llvm-svn: 369607

[GWP-ASan] Remove c++ standard lib dependency.

Remove c++ standard library dependency for now for @phosek. They have a
complicated build system that breaks with the fuzzer target here.

Also added a todo to remedy later.

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

llvm-svn: 369606

[analyzer] CastValueChecker: Store the dynamic types and casts

Summary:
This patch introduces `DynamicCastInfo` similar to `DynamicTypeInfo` which
is stored in `CastSets` which are storing the dynamic cast informations of
objects based on memory regions. It could be used to store and check the
casts and prevent infeasible paths.

Reviewed By: NoQ

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

llvm-svn: 369605

[analyzer] TrackConstraintBRVisitor: Do not track unknown values

Summary: -

Reviewers: NoQ, Szelethus

Reviewed By: NoQ, Szelethus

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

llvm-svn: 369604

gn build: Merge r369600

llvm-svn: 369603

[Object] FIX: update PlatformKind name in TapiFile

Buildbots that use GCC failed to compile because overwritten
namespace with variable name

llvm-svn: 369602

[TSan] #include header instead of forward declaring interceptees

llvm-svn: 369601

[Object] Add tapi files to object

Summary:
The intention for this is to allow reading and printing symbols out from
llvm-nm. Tapi file, and Tapi universal follow a similiar format to
their respective MachO Object format.

The tests are dependent on llvm-nm processing tbd files which is why its in D66160

Reviewers: ributzka, steven_wu, lhames

Reviewed By: ributzka, lhames

Subscribers: mgorny, hiraditya, dexonsmith, llvm-commits

Tags: #llvm

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

llvm-svn: 369600

[X86] Correct the scheduler classes for TAILJMP and TCRETURN CodeGenOnly instructions.

We had an odd combination of WriteJump applied to some memory
instructions and WriteJumpLd applied to register and immediate
instructions.

Thsi should hopefully assign them all correctly.

llvm-svn: 369599

[X86] Replace a couple hardcoded '5's with X86::AddrNumOperands for readability. NFC

llvm-svn: 369598

libcxx: Rename last two .hpp files in libcxx to .h

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

llvm-svn: 369597

[analyzer] Mention whether an event is about a condition in a bug report part 2

In D65724, I do a pretty thorough explanation about how I'm solving this
problem, I think that summary nails whats happening here ;)

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

llvm-svn: 369596

[test] Update test so it matches the Windows output

llvm-svn: 369595

gn build: Merge r369591

llvm-svn: 369594

gn build: Merge r369587

llvm-svn: 369593

[Attributor] FIX: Try to make bots happy

Locally the tight iterations bounds work fine but the bots seem unhappy.
Try to get green bots and some time to determine the underlying problem.

llvm-svn: 369592

[LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

Summary:
This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator
on the template is a DependentNameType - we can only put the gsl::Pointer attribute
on the underlaying record after instantiation)

inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared,
we added the gsl::Pointer on the canonical decl (the forward decl), and later when the
template was instantiated, there was no attribute on the definition so it was not instantiated).

and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to
a incomplete instantiation, and then another was copied from the template definition
when the instantiation was completed).

We now add the attributes to all redeclarations to fix thos issues and make their usage easier.

Reviewers: gribozavr

Subscribers: Szelethus, xazax.hun, cfe-commits

Tags: #clang

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

llvm-svn: 369591

[RISCV] Remove fix introduced by r369573, superseded by r369580

llvm-svn: 369590

[analyzer] Don't make ConditionBRVisitor events prunable when the condition is an interesting field

Exactly what it says on the tin! Note that we're talking about interestingness
in general, hence this isn't a control-dependency-tracking specific patch.

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

llvm-svn: 369589

[Attributor] Fix: Gracefully handle non-instruction users

Function can have users that are not instructions, e.g., bitcasts. For
now, we simply give up when we see them.

llvm-svn: 369588

Add FileWriter to GSYM and encode/decode functions to AddressRange and AddressRanges

The full GSYM patch started with: https://reviews.llvm.org/D53379

This patch add the ability to encode data using the new llvm::gsym::FileWriter class.

FileWriter is a simplified binary data writer class that doesn't require targets, target definitions, architectures, or require any other optional compile time libraries to be enabled via the build process. This class needs the ability to seek to different spots in the binary data that it produces to fix up offsets and sizes in GSYM data. It currently uses std::ostream over llvm::raw_ostream because llvm::raw_ostream doesn't support seeking which is required when encoding and decoding GSYM data.

AddressRange objects are encoded and decoded to be relative to a base address. This will be the FunctionInfo's start address if the AddressRange is directly contained in a FunctionInfo, or a base address of the containing parent AddressRange or AddressRanges. This allows address ranges to be efficiently encoded using ULEB128 encodings as we encode the offset and size of each range instead of full addresses. This also makes encoded addresses easy to relocate as we just need to relocate one base address.

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

llvm-svn: 369587

[Attributor][NFCI] Introduce tight iteration bounds in the tests

Summary:
To be able to track how many iterations we need to manifest all
information we check for we now make the maximum iteration count
explicit. The count is set tightly now and should be kept that way.

Reviewers: uenoku, sstefan1

Subscribers: bollu, llvm-commits

Tags: #llvm

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

llvm-svn: 369586

NFCI: Simplify SourceManager::translateFile by removing code path that should never be taken

I noticed that SourceManager::translateFile has code that doesn't really make sense.
In particular, if it fails to find a FileID by comparing FileEntry * values, it tries to
look through files that have the same filename, to see if they have a matching inode to try to
find the right FileID. However, the inode comparison seem redundant, as Clang's FileManager
already deduplicates FileEntry * values by inode.
Thus the comparisons between inodes should never actually succeed, and the comparison between FileEntry * values should be sufficient here.

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

llvm-svn: 369585

When building file without debug info, include the architecture
setting in the cflags on Darwin systems.

llvm-svn: 369584

[analyzer][NFC] Add different interestingness kinds

We defined (on the mailing list and here on phabricator) 2 different cases where
retrieving information about a control dependency condition is very important:

* When the condition's last write happened in a different stack frame
* When the collapse point of the condition (when we can constrain it to be
true/false) didn't happen in the actual condition.

It seems like we solved this problem with the help of expression value tracking,
and have started working on better diagnostics notes about this process.

Expression value tracking is nothing more than registering a variety of visitors
to construct reports about it. Each of the registered visitors (ReturnVisitor,
FindLastStoreVisitor, NoStoreFuncVisitor, etc) have something to go by: a
MemRegion, an SVal, an ExplodedNode, etc. For this reason, better explaining a
last write is super simple, we can always just pass on some more information to
the visitor in question (as seen in D65575).

ConditionBRVisitor is a different beast, as it was built for a different
purpose. It is responsible for constructing events at, well, conditions, and is
registered only once, and isn't a part of the "expression value tracking
family". Unfortunately, it is also the visitor to tinker with for constructing
better diagnostics about the collapse point problem.

This creates a need for alternative way to communicate with ConditionBRVisitor
that a specific condition is being tracked for for the reason of being a control
dependency. Since at almost all PathDiagnosticEventPiece construction the
visitor checks interestingness, it makes sense to pair interestingness with a
reason as to why we marked an entity as such.

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

llvm-svn: 369583

Add char8_t support (C++20)

This patch adds support for the char8_t type introduced in C++20
char8_t. The original patch was submitted by James Blachly  on the LLDB
mailing list [1]. I modified the patch a bit and added a test.

[1] http://lists.llvm.org/pipermail/lldb-dev/2019-August/015393.html

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

llvm-svn: 369582