This changes the 32-element SmallVector to a std::vector. When building
a RelWithDebInfo clang-8 binary, the average size of the vector was
~10000, so it does not seem very beneficial or practical to use a small
vector for that.

The DWARFBytes SmallVector grows in the same way as Comments, so perhaps
that also should be changed to a purely dynamically allocated structure,
but that requires some more code changes, so I let that remain as a
SmallVector for now.

llvm-svn: 374871

Check if size of operand LLT matches sizes of available register banks
before inspecting the opcode in order to reduce number of checks.
Factor commonly used pieces of code into functions.

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

llvm-svn: 374870

This makes use of it slightly clearer, and makes it match the
same construct in the lld ELF linker.

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

llvm-svn: 374869

This #define is in the non-Go ppc64le build but not in the Go build.

Reviewed-in: https://reviews.llvm.org/D68046
Author: randall77 (Keith Randall)
llvm-svn: 374868

This matches all other architectures listed in the same file.

This fixes debugging aarch64 executables with lldb-server, which
otherwise fails, with log messages like these:

Target::SetArchitecture changing architecture to aarch64 (aarch64-pc-windows-msvc)
Target::SetArchitecture Trying to select executable file architecture aarch64 (aarch64-pc-windows-msvc)

ArchSpec::SetArchitecture sets the vendor to llvm::Triple::PC
for any coff/win32 combination, and if this doesn't match the triple
set by the PECOFF module, things doesn't seem to work with when
using lldb-server.

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

llvm-svn: 374867

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

llvm-svn: 374866

This corresponds to commonly used options to UnDecorateSymbolName
within llvm.

Add them as hidden options in llvm-undname. MS undname.exe takes
numeric flags, corresponding to the UNDNAME_* constants, but instead
of hardcoding in mappings for those numbers, just add textual
options instead, as it the use of them here is primarily intended
for testing.

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

llvm-svn: 374865

llvm-svn: 374864

- use a full triple instead of just the architecture (makes the test
  pass on non-apple hosts)
- skip the test if the ARM llvm target is not built

llvm-svn: 374863

[X86] Don't check for VBROADCAST_LOAD being a user of the source of a VBROADCAST when trying to share broadcasts.

The only things VBROADCAST_LOAD uses is an address and a chain
node. It has no vector inputs.

So if its a user of the source of another broadcast that could
only mean one of two things. The other broadcast is broadcasting
the address of the broadcast_load. Or the source is a load and
the use we're seeing is the chain result from that load. Neither
of these cases make sense to combine here.

This issue was reported post-commit r373871. Test case has not
been reduced yet.

llvm-svn: 374862

This reverts r374692 (git commit 92694eba)

Reproducer sent to commit thread on llvm-commits.

llvm-svn: 374859

LLVM may annotate the function with fastcc if there has only one caller
and there're no other caller out of the module and the function is not
naked or contain variable arguments.

The fastcc functions could pass the arguments by the caller saved registers.

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

llvm-svn: 374857

Summary:
The WebAssembly backend lowers fptoint instructions to a code sequence
that checks for overflow to avoid traps because fptoint is supposed to
be speculatable. These new builtins and intrinsics give users a way to
depend on the trapping semantics of the underlying instructions and
avoid the extra code generated normally.

Patch by coffee and tlively.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 374856

...instead of `<ciso646>`.

Also includes some NFC comment changes.

llvm-svn: 374854

By default `platform process list` only shows the processes of the current user that lldb-server can parse.
There are several problems:
- apk programs don't have an executable file. They instead use a package name as identifier. We should show them instead.
- each apk also runs under a different user. That's how android works
- because of the user permission, some files like /proc/<pid>/{environ,exe} can't be read.

This results in a very small process list.

This is a local run on my machine
```
(lldb) platform process list
2 matching processes were found on "remote-android"
PID    PARENT USER       TRIPLE                   NAME
====== ====== ========== ======================== ============================
23291  3177              aarch64-unknown-linux-android sh
23301  23291            aarch64-unknown-linux-android lldb-server
```
However, I have 700 processes running at this time.

By implementing a few fallbacks for android, I've expanded this list to 202, filtering out kernel processes, which would presumably appear in this list if the device was rooted.

```
(lldb) platform process list
202 matching processes were found on "remote-android"
PID    PARENT USER       TRIPLE                   NAME
====== ====== ========== ======================== ============================
...
12647  3208              aarch64-unknown-linux-android sh
12649  12647             aarch64-unknown-linux-android lldb-server
12653  982                                        com.samsung.faceservice
13185  982                                        com.samsung.vvm
15899  982                                        com.samsung.android.spay
16220  982                                        com.sec.spp.push
17126  982                                        com.sec.spp.push:RemoteDlcProcess
19772  983                                        com.android.chrome
20209  982                                        com.samsung.cmh:CMH
20380  982                                        com.google.android.inputmethod.latin
20879  982                                        com.samsung.android.oneconnect:Receiver
21212  983                                        com.tencent.mm
24459  1                 aarch64-unknown-linux-android wpa_supplicant
25974  982                                        com.samsung.android.contacts
26293  982                                        com.samsung.android.messaging
28714  982                                        com.samsung.android.dialer
31605  982                                        com.samsung.android.MtpApplication
32256  982                                        com.bezobidny
```

Something to notice is that the architecture is unkonwn for all apks. And that's fine, because run-as would be required to gather this information and that would make this entire functionality massively slow.

There are still several improvements to make here, like displaying actual user names, which I'll try to do in a following diff.

Note: Regarding overall apk debugging support from lldb. I'm planning on having lldb spawn lldb-server by itself with the correct user, so that everything works well. The initial lldb-server used for connecting to the remote platform can be reused for such purpose. Furthermore, eventually lldb could also launch that initial lldb-server on its own.

Differential Revision: D68289

llvm-svn: 374853

This reverts commit d8af64c9a0228301f6fd0e1c841e4abe0b6f4801.

llvm-svn: 374852

This reverts r374828 (git commit 1f40f15d) due to bot breakage

llvm-svn: 374851

Update MSSA for blocks cloned when doing partial unswitching.
Enable additional testing with MSSA.
Resolves PR43641.

llvm-svn: 374850

[X86] Teach X86MCodeEmitter to properly encode zmm16-zmm31 as index register to vgatherpf/vscatterpf.

We need to encode bit 4 into the EVEX.V' bit. We do this right
for regular gather/scatter which use either MRMSrcMem or MRMDestMem
formats.  The prefetches use MRM*m formats.

Fixes an issue recently added to PR36202.

llvm-svn: 374849

llvm-svn: 374848

llvm-svn: 374847

llvm-svn: 374846

This reverts commit 9f6a8732.

llvm-svn: 374844

as it's breaking a few bots.

This reverts r374841 (git commit 2a1386c8)

llvm-svn: 374842

Summary:
When files often get touched during builds, the mtime based validation
leads to different problems in implicit modules builds, even when the
content doesn't actually change:

- Modules only: module invalidation due to out of date files. Usually causing rebuild traffic.
- Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH.
- PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime.

This patch proposes hashing the content of input files (headers and
module maps), which is performed during serialization time. When looking
at input files for validation, clang only computes the hash in case
there's a mtime mismatch.

I've tested a couple of different hash algorithms availble in LLVM in
face of building modules+pch for `#import <Cocoa/Cocoa.h>`:
- `hash_code`: performace diff within the noise, total module cache increased by 0.07%.
- `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`.
- `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file.

Given the numbers above, the patch uses `hash_code`. The patch also
improves invalidation error msgs to point out which type of problem the
user is facing: "mtime", "size" or "content".

rdar://problem/29320105

Reviewers: dexonsmith, arphaman, rsmith, aprantl

Subscribers: jkorous, cfe-commits, ributzka

Tags: #clang

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

llvm-svn: 374841

we're running and to make flipping the default not regress testing.

llvm-svn: 374840

we will unroll loops. Also comment a few occasions where we need to
know whether or not we're forcing the unwinder or not.

The default before and after this patch is for LoopUnroll to be enabled,
and for it to use a cost model to determine whether to unroll the loop
(`OnlyWhenForced = false`). Before this patch, disabling loop unroll
would not run the LoopUnroll pass. After this patch, the LoopUnroll pass
is being run, but it restricts unrolling to only the loops marked by a
pragma (`OnlyWhenForced = true`).

In addition, this patch disables the UnrollAndJam pass when disabling unrolling.

Testcase is in clang because it's controlling how the loop optimizer
is being set up and there's no other way to trigger the behavior.

llvm-svn: 374838

Include linux as a test requirement.

llvm-svn: 374837

The version mismatch symbol is version 9 on 32 bit android. Since
this test isn't actually testing any android specific functionality,
we force the target triple to x86_64-unknown-unknown in order to have
a consistent version number. It seems the test was already trying to
do this, just not doing it right

Patch by Christopher Tetrault

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

llvm-svn: 374836

Mostly because we don't appear to have one and a prototype patch I just saw would have broken the example committed.

llvm-svn: 374835

Summary:
Currently clang does not support -Wa,-W, which suppresses warning
messages in GNU assembler. Add this option for gcc compatibility.
https://bugs.llvm.org/show_bug.cgi?id=43651. Reland with differential
information.

Reviewers: bcain

Reviewed By: bcain

Subscribers: george.burgess.iv, gbiv, llozano, manojgupta, nickdesaulniers, cfe-commits

Tags: #clang

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

llvm-svn: 374834

This reverts commit e72eeca43b9577be2aae55f7603febbf223a6ab3.

llvm-svn: 374833

Summary:
Integrated assembler does not accept offset expressions surrounded by
parenthesis. Handle this case for GAS compability.
https://bugs.llvm.org/show_bug.cgi?id=43631

Subscribers: kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 374832

Introduced in r374582, Michael Spencer pointed out this broke the
modules build due to a missing tblgen dependency on
llvm/IR/Attributes.inc.

Michael fixed the dependency in r374827.

So this removes the inclusion and the new dependency (effectively
reverting r374827 and including the alternative fix of removing rather
than supporting the new dependency).

Thanks for the quick fix/notice, Michael!

llvm-svn: 374831

previously we would generate literal check lines w/ no reg-exps for
vregs as MI flags (nsw, ninf, etc.) won't be recognized as a part of MI.

Fixing that. Includes updating the MIR tests that suffered from the
problem.

Reviewed By: bogner

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

llvm-svn: 374829

For a constant shift amount, add the following fold.
shl (zext (i1 X)), ShAmt --> select (X, 1 << ShAmt, 0)

https://rise4fun.com/Alive/IZ9

Fixes PR42257.

Based on original patch by @zvi (Zvi Rackover)

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

llvm-svn: 374828

A previous commit made libLLVMDebugInfoDWARF depend on the LLVM_Bitcode module which depends on the LLVM_intrinsic_gen module which depends on "llvm/IR/Attributes.inc" which is a generated header not depended on by libLLVMDebugInfo. Add that dependency.

llvm-svn: 374827

Summary:
We don't know what context to use until the classification result is
consumed by the parser, which could happen in a different semantic
context. So don't build the expression that results from name
classification until we get to that point and can handle it properly.

This covers everything except C++ implicit class member access, which
is a little awkward to handle properly in the face of the protected
member access check. But it at least fixes all the currently-filed
instances of PR43080.

Reviewers: efriedma

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 374826

oops!  I cherry-picked  rL374820 thinking it was completely
independent of D68737, but it wasn't.  It makes an incidental
use of SBFile::GetFile, which is introduced there, so I broke the
build.

The docs say you can commit without review for "obvious".   I think
this qualifies.   If this kind of fix isn't considered obvious, let
me know and I'll revert instead.

Fixes: rL374820
llvm-svn: 374825

Reviewed By: rnk

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

llvm-svn: 374823