[NFC][x86][AArch64] extract-bits.ll: add test with 'ashr'.

llvm-svn: 346121

[hwasan] Fix stack-uar.c after rCRT345110

Set -fno-discard-value-names so that the frame description string contains the variable name.

llvm-svn: 346120

[DAGCombiner] Use tryFoldToZero to simplify some code and make it work correctly between LegalTypes and LegalOperations.

The original code avoided creating a zero vector after type legalization, but if we're after type legalization the type we have is legal. The real hazard we need to avoid is creating a build vector after op legalization. tryFoldToZero takes care of checking for this.

llvm-svn: 346119

[DAGCombiner] Remove an unused argument from tryFoldToZero. NFC

llvm-svn: 346118

[AVR] Fix a backend bug that left extraneous operands after expansion

This patch fixes a bug in the AVR FRMIDX expansion logic.

The expansion would leave a leftover operand from the original FRMIDX,
but now attached to a MOVWRdRr instruction. The MOVWRdRr instruction
did not expect this operand and so LLVM rejected the machine
instruction.

This would trigger an assertion:

    Assertion failed: ((isImpReg || Op.isRegMask() || MCID->isVariadic() ||
                        OpNo < MCID->getNumOperands() || isMetaDataOp) &&
                        "Trying to add an operand to a machine instr that is already done!"),
    function addOperand, file llvm/lib/CodeGen/MachineInstr.cpp

Tim fixed this so that now the FRMIDX is expanded correctly into
a well-formed MOVWRdRr.

Patch by Tim Neumann

llvm-svn: 346117

[XRay] Update TSC math to handle wraparound

Summary:
Prior to this change, we can run into situations where the TSC we're
getting when exiting a function is less than the TSC we got when
entering it. This would sometimes cause the counter for cumulative call
times overflow, which was erroneously also being stored as a signed
64-bit integer.

This change addresses both these issues while adding provisions for
tracking CPU migrations. We do this because moving from one CPU to
another doesn't guarantee that the timestamp counter for some
architectures aren't guaranteed to be synchronised. For the moment, we
leave the provisions there until we can update the data format to
include the counting of CPU migrations we can catch.

We update the necessary tests as well, ensuring that our expectations
for the cycle accounting to be met in case of counter wraparound.

Reviewers: mboerger

Subscribers: llvm-commits

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

llvm-svn: 346116

[X86] Custom type legalize v2i8/v2i16/v2i32 mul to use to pmuludq.

v2i8/v2i16/v2i32 are promoted to v2i64. pmuludq takes a v2i64 input and produces a v2i64 output. Since we don't about the upper bits of the type legalized multiply we can use the pmuludq to produce the multiply result for the bits we do care about.

llvm-svn: 346115

[AVR] Disallow the LDDWRdPtrQ instruction with Z as the destination

This is an AVR-specific workaround for a limitation of the register
allocator that only exposes itself on targets with high register
contention like AVR, which only has three pointer registers.

The three pointer registers are X, Y, and Z.
In most nontrivial functions, Y is reserved for the frame pointer,
as per the calling convention. This leaves X and Z. Some instructions,
such as LPM ("load program memory"), are only defined for the Z
register. Sometimes this just leaves X.

When the backend generates a LDDWRdPtrQ instruction with Z as the
destination pointer, it usually trips up the register allocator
with this error message:

  LLVM ERROR: ran out of registers during register allocation

This patch is a hacky workaround. We ban the LDDWRdPtrQ instruction
from ever using the Z register as an operand. This gives the
register allocator a bit more space to allocate, fixing the
regalloc exhaustion error.

Here is a description from the patch author Peter Nimmervoll

  As far as I understand the problem occurs when LDDWRdPtrQ uses
  the ptrdispregs register class as target register. This should work, but
  the allocator can't deal with this for some reason. So from my testing,
  it seams like (and I might be totally wrong on this) the allocator reserves
  the Z register for the ICALL instruction and then the register class
  ptrdispregs only has 1 register left and we can't use Y for source and
  destination. Removing the Z register from DREGS fixes the problem but
  removing Y register does not.

More information about the bug can be found on the avr-rust issue
tracker at https://github.com/avr-rust/rust/issues/37.

A bug has raised to track the removal of this workaround and a proper
fix; PR39553 at https://bugs.llvm.org/show_bug.cgi?id=39553.

Patch by Peter Nimmervoll

llvm-svn: 346114

[analyzer] Restrict AnalyzerOptions' interface so that non-checker objects have to be registered

One of the reasons why AnalyzerOptions is so chaotic is that options can be
retrieved from the command line whenever and wherever. This allowed for some
options to be forgotten for a looooooong time. Have you ever heard of
"region-store-small-struct-limit"? In order to prevent this in the future, I'm
proposing to restrict AnalyzerOptions' interface so that only checker options
can be retrieved without special getters. I would like to make every option be
accessible only through a getter, but checkers from plugins are a thing, so I'll
have to figure something out for that.

This also forces developers who'd like to add a new option to register it
properly in the .def file.

This is done by

* making the third checker pointer parameter non-optional, and checked by an
  assert to be non-null.
* I added new, but private non-checkers option initializers, meant only for
  internal use,
* Renamed these methods accordingly (mind the consistent name for once with
  getBooleanOption!):
  - getOptionAsString -> getCheckerStringOption,
  - getOptionAsInteger -> getCheckerIntegerOption
* The 3 functions meant for initializing data members (with the not very
  descriptive getBooleanOption, getOptionAsString and getOptionAsUInt names)
  were renamed to be overloads of the getAndInitOption function name.
* All options were in some way retrieved via getCheckerOption. I removed it, and
  moved the logic to getStringOption and getCheckerStringOption. This did cause
  some code duplication, but that's the only way I could do it, now that checker
  and non-checker options are separated. Note that the non-checker version
  inserts the new option to the ConfigTable with the default value, but the
  checker version only attempts to find already existing entries. This is how
  it always worked, but this is clunky and I might end reworking that too, so we
  can eventually get a ConfigTable that contains the entire configuration of the
  analyzer.

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

llvm-svn: 346113

Ensure the correct order of evaluation in part 2. of PlistMacroExpansion

Windows buildbots break with the previous commit '[analyzer][PlistMacroExpansion]
Part 2.: Retrieving the macro name and primitive expansion'. This patch attempts
to solve this issue.

llvm-svn: 346112

Reland '[analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and primitive expansion'

llvm-svn: 346111

[X86] Fix typo in test comment. NFC

llvm-svn: 346110

[LLDB] Fix FreeBSD/Darwin build

Reviewers: JDevlieghere, tatyana-krasnukha

Reviwed By: tatyana-krasnukha

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

llvm-svn: 346109

[HotColdSplitting] Use TTI to inform outlining threshold

Using TargetTransformInfo allows the splitting pass to factor in the
code size cost of instructions as it decides whether or not outlining is
profitable.

This did not regress the overall amount of outlining seen on the handful
of internal frameworks I tested.

Thanks to Jun Bum Lim for suggesting this!

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

llvm-svn: 346108

[Driver] Use -Bstatic/dynamic for libc++ on Fuchsia

-static relies on lld's behavior, but -Bstatic/dynamic is supported
across all linkers.

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

llvm-svn: 346107

[X86] Add nounwind to some tests to remove cfi directives from checks. NFC

llvm-svn: 346106

[X86] Regenerate test checks to merge 32 and 64 bit. Remove stale check prefixes. NFC

llvm-svn: 346105

Fix the test for partition_copy so it is not ridiculously slow. Also, detab.

llvm-svn: 346104

Add support of the next Ubuntu (Ubuntu 19.04 - Disco Dingo)

llvm-svn: 346103

[X86] Add vector shift by immediate to SimplifyDemandedBitsForTargetNode.

Summary: This also enables some constant folding from KnownBits propagation. This helps on some cases vXi64 case in 32-bit mode where constant vectors appear as vXi32 and a bitcast. This can prevent getNode from constant folding sra/shl/srl.

Reviewers: RKSimon, spatel

Reviewed By: spatel

Subscribers: llvm-commits

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

llvm-svn: 346102

Update our URLs in clang doc to use https

llvm-svn: 346101

Fix NetBSD build after "Move path resolution logic out of FileSpec"

D53915

llvm-svn: 346100

Update framework-header-fix to force system sed

Summary:
There are 2 changes here:

1. Use system sed instead of the sed found in the user's path. This
     fixes this script in the case the user has gnu-sed in their $PATH before
     bsd sed since `-i ''` isn't compatible and you need `-i` instead.

2. `set -e` in this script so it fails as soon as one of these commands
     fail instead of throwing errors for each file if they fail

Since this is only ran on macOS, and we're already using this
absolute path below, this seems like a safe addition

Reviewers: kastiglione, beanz

Reviewed By: kastiglione

Subscribers: lldb-commits

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

llvm-svn: 346099

Disable recursive interception for tzset in MSan

This fixes sanitization of this library call on NetBSD.
Extracted as a part of D42050.

llvm-svn: 346098

[ValueTracking] determine sign of 0.0 from select when matching min/max FP

In PR39475:
https://bugs.llvm.org/show_bug.cgi?id=39475
..we may fail to recognize/simplify fabs() in some cases because we do not
canonicalize fcmp with a -0.0 operand.

Adding that canonicalization can cause regressions on min/max FP tests, so
that's this patch: for the purpose of determining whether something is min/max,
let the value returned by the select determine how we treat a 0.0 operand in the fcmp.

This patch doesn't actually change the -0.0 to +0.0. It just changes the analysis, so
we don't fail to recognize equivalent min/max patterns that only differ in the
signbit of 0.0.

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

llvm-svn: 346097

Revert '[analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and primitive expansion'

llvm-svn: 346096

[analyzer][PlistMacroExpansion] Part 2.: Retrieving the macro name and primitive expansion

This patch adds a couple new functions to acquire the macro's name, and also
expands it, although it doesn't expand the arguments, as seen from the test files

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

llvm-svn: 346095

Fix log statement in r346093

Thanks to Dávid Bolvanský for pointing that out.

llvm-svn: 346094

NativeProcessProtocol: Simplify breakpoint setting code

Summary:
A fairly simple operation as setting a breakpoint (writing a breakpoint
opcode) at a given address was going through three classes:
NativeProcessProtocol which called NativeBreakpointList, which then
called SoftwareBrekpoint, only to end up again in NativeProcessProtocol
to do the actual writing itself. This is unnecessarily complex and can
be simplified by moving all of the logic into NativeProcessProtocol
class itself, removing a lot of boilerplate.

One of the reeasons for this complexity was that (it seems)
NativeBreakpointList class was meant to hold both software and hardware
breakpoints. However, that never materialized, and hardware breakpoints
are stored in a separate map holding only hardware breakpoints.
Essentially, this patch makes software breakpoints follow that approach
by replacing the heavy SoftwareBraekpoint with a light struct of the
same name, which holds only the data necessary to describe one
breakpoint. The rest of the logic is in the main class. As, at the
lldb-server level, handling software and hardware breakpoints is very
different, this seems like a reasonable state of things.

Reviewers: krytarowski, zturner, clayborg

Subscribers: mgorny, lldb-commits

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

llvm-svn: 346093

[DAGCombiner] Remove 'else' after return. NFC

This makes this code consistent with the nearly identical code in visitZERO_EXTEND.

llvm-svn: 346090

Fix duplicate testcase filename

dotest.py started reporting:
Exception: Found multiple tests with the name TestSampleTest.py
After the commit of:
https://reviews.llvm.org/D54056

llvm-svn: 346089

[Driver] Always match resource dir in Fuchsia driver tests

This makes the tests stricter by not only matching the runtime file
name, but the entire path into the resource directory.

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

llvm-svn: 346088

[SelectionDAG] Remove special methods for creating *_EXTEND_VECTOR_INREG nodes. Move asserts into getNode.

These methods were just wrappers around getNode with additional asserts (identical and repeated 3 times). But getNode already has a switch that can be used to hold these asserts that allows them to be shared for all 3 opcodes. This also enables checking on the places that create these nodes without using the wrappers.

The rest of the patch is just changing all callers to use getNode directly.

llvm-svn: 346087

Remove redundant OVERRRIDES file

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 346086

configure: Provide symlink for amdgcn-mesa3d instead of configure hack

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 346085

travis: Check tahiti-amdgcn-mesa-mesa3d.bc

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 346084

amdgcn-amdhsa: Convert get_{global,local}_size to clc for all llvm versions

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Acked-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 346083

amdgcn: Move __clc_amdgcn_s_waitcnt definition to clc file

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 346082

amdgcn: Convert get_num_groups to clc

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 346081

amdgcn: Convert get_global_size to clc

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 346080

amdgcn: Convert get_local_size to clc

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 346079

r600: Convert barrier to clc

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewer: Aaron Watry
llvm-svn: 346078

r600: Convert get_num_groups to clc

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewer: Aaron Watry
llvm-svn: 346077

r600: Convert get_global_size to clc

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewer: Aaron Watry
llvm-svn: 346076

r600: Convert get_local_size to clc

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewer: Aaron Watry
llvm-svn: 346075

[coroutines] Fix fallthrough warning on try/catch

Summary:
The test case added in this diff would incorrectly warn that control
flow may fall through without returning. Here's a standalone example:
https://godbolt.org/z/dCwXEi

The same program, but using `return` instead of `co_return`, does not
produce a warning: https://godbolt.org/z/mVldqQ

The issue was in how Clang analysis would structure its representation
of the control-flow graph. Specifically, when constructing the CFG,
`CFGBuilder::Visit` had special handling of a `ReturnStmt`, in which it
would place object destructors in the same CFG block as a `return` statement,
immediately after it. Doing so would allow the logic in
`lib/Sema/AnalysisBasedWarning.cpp` `CheckFallThrough` to work properly in the
program that used `return`, correctly determining that no "plain edges" preceded
the exit block of the function.

Because a `co_return` statement would not enjoy the same treatment when
it was being built into the control-flow graph, object destructors
would not be placed in the same CFG block as the `co_return`, thus
resulting in a "plain edge" preceding the exit block of the function,
and so the warning logic would be triggered.

Add special casing for `co_return` to Clang analysis, thereby
remedying the mistaken warning.

Test Plan: `check-clang`

Reviewers: GorNishanov, tks2103, rsmith

Reviewed By: GorNishanov

Subscribers: EricWF, lewissbaker, cfe-commits

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

llvm-svn: 346074

[X86] Update comment I forgot to change in r346043. NFC

llvm-svn: 346073

[NFC] Fix incorrect comment in std::list

llvm-svn: 346072

[ValueTracking] peek through 2-input shuffles in ComputeNumSignBits

This patch gives the IR ComputeNumSignBits the same functionality as the
DAG version (the code is derived from the existing code).

This an extension of the single input shuffle analysis added with D53659.

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

llvm-svn: 346071

Fix test on Windows.

This test checks the entire output of a help option, the problem
is that on Windows, the line break occurs in a different place
causing the CHECK to fail because it is not expecting a line break.

llvm-svn: 346070

Add /Zc:DllexportInlines option to clang-cl

Summary:
This CL adds /Zc:DllexportInlines flag to clang-cl.
When Zc:DllexportInlines- is specified, inline class member function is not exported if the function does not have local static variables.

By not exporting inline function, code for those functions are not generated and that reduces both compile time and obj size. Also this flag does not import inline functions from dllimported class if the function does not have local static variables.

On my 24C48T windows10 machine, build performance of chrome target in chromium repository is like below.
These stats are come with 'target_cpu="x86" enable_nacl = false is_component_build=true dcheck_always_on=true` build config and applied
* https://chromium-review.googlesource.com/c/chromium/src/+/1212379
* https://chromium-review.googlesource.com/c/v8/v8/+/1186017

Below stats were taken with this patch applied on https://github.com/llvm-project/llvm-project-20170507/commit/a05115cd4c57ff76b0f529e38118765b58ed7f2e

| config                          | build time | speedup | build dir size |
| with patch, PCH on, debug       | 1h10m0s    | x1.13   | 35.6GB         |
| without patch, PCH on, debug    | 1h19m17s   |         | 49.0GB         |
| with patch, PCH off, debug      | 1h15m45s   | x1.16   | 33.7GB         |
| without patch, PCH off, debug   | 1h28m10s   |         | 52.3GB         |
| with patch, PCH on, release     | 1h13m13s   | x1.22   | 26.2GB         |
| without patch, PCH on, release  | 1h29m57s   |         | 37.5GB         |
| with patch, PCH off, release    | 1h23m38s   | x1.32   | 23.7GB         |
| without patch, PCH off, release | 1h50m50s   |         | 38.7GB         |

This patch reduced obj size and the number of exported symbols largely, that improved link time too.
e.g. link time stats of blink_core.dll become like below
|                              | cold disk cache | warm disk cache |
| with patch, PCH on, debug    | 71s             | 30s             |
| without patch, PCH on, debug | 111s            | 48s             |

This patch's implementation is based on Nico Weber's patch. I modified to support static local variable, added tests and took stats.

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

Reviewers: hans, thakis, rnk, javed.absar

Reviewed By: hans

Subscribers: kristof.beyls, smeenai, dschuff, probinson, cfe-commits, eraman

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

llvm-svn: 346069

Handle OUTPUT_FORMAT arguments in quotation marks

llvm-svn: 346068

Test commit

llvm-svn: 346067

[debuginfo-tests] commands.getoutput -> subprocess.check_output

We should also make Darwin Python3 happy after r346059
The output has an extra newline but it is fine in this particular case.

llvm-svn: 346066

Revert r345562: "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type"

This exposes a (known) CodeGen bug: it can't cope with emitting lvalue
expressions that denote non-odr-used but usable-in-constant-expression
variables. See PR39528 for a testcase.

Reverted for now until that issue can be fixed.

llvm-svn: 346065

[Driver] Use -push-/-pop-state and -as-needed for libc++ on Fuchsia

This avoids introducing unnecessary DT_NEEDED entries when using
C++ driver for linking C code or C++ code that doesn't use C++
standard library.

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

llvm-svn: 346064

[compiler-rt] Support for passing through linker flags to libc++ build

This may be needed when cross-compiling to certain platforms.

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

llvm-svn: 346063

[codeview] Let the X86 backend tell us the VFRAME offset adjustment

Use MachineFrameInfo's OffsetAdjustment field to pass this information
from the target to CodeViewDebug.cpp. The X86 backend doesn't use it for
any other purpose.

This fixes PR38857 in the case where there is a non-aligned quantity of
CSRs and a non-aligned quantity of locals.

llvm-svn: 346062

[DWARF v5] Verifier: Add checks for DW_FORM_strx* forms.

Adding functionality to the DWARF verifier for DWARF v5 strx* forms which
index into the string offsets table.

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

llvm-svn: 346061

Update debuginfo tests lit for r341135

llvm-svn: 346060

[debuginfo-tests] Avoid "import commands" which was deprecated in Py3

llvm-svn: 346059

Fix some windows-specific fallout from the FileSpec change.

llvm-svn: 346058

Make sure to have lit load the configured site config first.

For the lldb unit test suite, we forgot to add the mapping from
site config to main config, so when it found the main config in
the source tree, it wasn't going and loading the configured version
in the build tree first, so the required properties weren't getting
set up properly.

llvm-svn: 346057

[CMake][Fuchsia] Set -fuse-ld=lld explicitly for Linux runtimes

We set lld as the default linker on non-Darwin platforms, but we still
need to set -fuse-ld=lld explicitly in to support cross-compiling Linux
runtimes on Darwin.

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

llvm-svn: 346056

[LTO] Fix a crash caused by accessing an empty ValueInfo

ModuleSummaryIndex::exportToDot crashes when linking the Linux kernel
under ThinLTO using LLVMgold.so. This is due to the exportToDot
function trying to get the GUID of an empty ValueInfo. The root cause
related to the fact that we attempt to get the GUID of an aliasee
via its OriginalGUID recorded in the aliasee summary, and that is not
always possible. Specifically, we cannot do this mapping when the value
is internal linkage and there were other internal linkage symbols with
the same name.

There are 2 fixes for the problem included here.

1) In all cases where we can currently print the dot file from the
command line (which is only via save-temps), we have a valid AliaseeGUID
in the AliasSummary. Use that when it is available, so that we can get
the correct aliasee GUID whenever possible.

2) However, if we were to invoke exportToDot from the debugger right
after it is built during the initial analysis step (i.e. the per-module
summary), we won't have the AliaseeGUID field populated. In that case,
we have a fallback fix that will simply print "@"+GUID when we aren't
able to get the GUID from the OriginalGUID. It simply checks if the VI
is valid or not before attempting to get the name. Additionally, since
getAliaseeGUID will assert that the AliaseeGUID is non-zero, guard the
earlier fix #1 by a new function hasAliaseeGUID().

Reviewers: pcc, tmroeder

Subscribers: evgeny777, mehdi_amini, inglorion, dexonsmith, arphaman, llvm-commits

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

llvm-svn: 346055

[clangd] don't buffer the input-mirror stream, it's used to diagnose crashes

llvm-svn: 346054

Add an SBExpressionOptions setting mirroring the "exec" command's --allow-jit.

<rdar://problem/44809176>

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

llvm-svn: 346053

[compiler-rt][Fuzzer] Fix the fuzzer test build

This fixes the issue introduced in r345765 which changed the way in
which the embedded libc++ is being built but omitted tests.

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

llvm-svn: 346052

Workaround using new Clang with an old NDK.

We're using an old NDK and a new Clang. New Clangs default to
`-stdlib=libc++` for Android, but those libraries cannot be found by
default with an old NDK. Use an explicit `-stdlib=libstdc++` in the
cxx_mode_flags.

llvm-svn: 346051

[X86] In LowerEXTEND_VECTOR_INREG, emit a vector shuffle instead of directly using X86ISD::UNPCKL

The majority of the changes are because the rest of shuffle lowering/combining prefers to replace the undef input with the other operand. Using UNPCKL directly seemed to avoid this and just grabbed a randomish register for the undef which can create false dependencies.

llvm-svn: 346050

[FileSystem] Open File instances through the FileSystem.

This patch modifies how we open File instances in LLDB. Rather than
passing a path or FileSpec to the constructor, we now go through the
virtual file system. This is needed in order to make things work with
the VFS in the future.

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

llvm-svn: 346049

Add an explicit -std=c++14 to this test.

rdar://problem/45642490

llvm-svn: 346048

[WebAssembly] Parsing missing directives to produce valid .o

Summary:
The assembler was able to assemble and then dump back to .s, but
was failing to parse certain directives necessary for valid .o
output:
- .type directives are now recognized to distinguish function symbols
  and others.
- .size is now parsed to provide function size.
- .globaltype (introduced in https://reviews.llvm.org/D54012) is now
  recognized to ensure symbols like __stack_pointer have a proper type
  set for both .s and .o output.

Also added tests for the above.

Reviewers: sbc100, dschuff

Subscribers: jgravelle-google, aheejin, dexonsmith, kristina, llvm-commits, sunfish

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

llvm-svn: 346047

Fix the lit test suite.

This change was accidentally missed from the original changeset.

llvm-svn: 346046

Revert "[Symbol] Search symbols with name and type in a symbol file"

It broke MacOS buildbots.

llvm-svn: 346045

[COFF, ARM64] Implement InterlockedExchange*_* builtins

Summary: Windows SDK needs these intrinsics to be proper builtins.  This is second in a series of patches to move intrinsic defintions out of intrin.h.

Reviewers: rnk, mstorsjo, efriedma, TomTan

Reviewed By: rnk, efriedma

Subscribers: javed.absar, kristof.beyls, chrib, jfb, kristina, cfe-commits

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

llvm-svn: 346044

[X86] Don't emit *_extend_vector_inreg nodes when both the input and output types are legal with AVX1

We already have custom lowering for the AVX case in LegalizeVectorOps. So its better to keep the regular extend op around as long as possible.

I had to qualify one place in DAG combine that created illegal vector extending load operations. This change by itself had no effect on any tests which is why its included here.

I've made a few cleanups to the custom lowering. The sign extend code no longer creates an identity shuffle with undef elements. The zero extend code now emits a zero_extend_vector_inreg instead of an unpckl with a zero vector.

For the high half of the custom lowering of zero_extend/any_extend, we're now using an unpckh with a zero vector or undef. Previously we used used a pshufd to move the upper 64-bits to the lower 64-bits and then used a zero_extend_vector_inreg. I think the zero vector should require less execution resources and be smaller code size.

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

llvm-svn: 346043

Try to unbreak the build of sanitizers on !NetBSD

Include the build of unpoison_passwd() and unpoison_group() for
SANITIZER_INTERCEPT_FGETPWENT_R and SANITIZER_INTERCEPT_FGETGRENT_R.
 static void unpoison_passwd(

llvm-svn: 346042

Diagnose parameter names that shadow the names of inherited fields under -Wshadow-field.

This addresses PR34120. Note, unlike GCC, we take into account the accessibility of the field when deciding whether to warn or not.

llvm-svn: 346041

[DWARF] Fix typo, .gnu_index -> .gdb_index

llvm-svn: 346040

[DWARF] Fix typo, .gnu_index -> .gdb_index

llvm-svn: 346039

Split getpwent and fgetgrent functions in interceptors

Summary:
NetBSD does not ship with fgetpwent_r() and fgetgrent_r().
Split their interceptors from getpwent_r() and getgrent_r()
and disable for this OS.

Installation of supernumerary interceptors causes leaking of
errors to dlsym(3)-like operations.

No functional change for other OSes.

Reviewers: vitalybuka, joerg

Reviewed By: vitalybuka

Subscribers: srhines, kubamracek, fedor.sergeev, llvm-commits, #sanitizers, mgorny

Tags: #sanitizers

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

llvm-svn: 346038

[AArch64] [Windows] Misc fixes for llvm-readobj -unwind.

Use getImageBase() helper to compute the image base. Fix various
offsets/addresses/masks so they're actually correct.

This allows decoding unwind info from DLLs, and unwind info from object
files containing multiple functions.

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

llvm-svn: 346036

Fix a bug in the lit test suite generation.

I'm not sure why this has to be CMAKE_CURRENT_SOURCE_DIR, but
it causes all kinds of strange cmake generation errors when it's
the binary dir.

llvm-svn: 346035

[RISCV] Add some missing expansions for floating-point intrinsics

A number of intrinsics, such as llvm.sin.f32, would result in a failure to
select. This patch adds expansions for the relevant selection DAG nodes, as
well as exhaustive testing for all f32 and f64 intrinsics.

The codegen for FMA remains a TODO item, pending support for the various
RISC-V FMA instruction variants.

The llvm.minimum.f32.* and llvm.maximum.* tests are commented-out, pending
upstream support for target-independent expansion, as discussed in
http://lists.llvm.org/pipermail/llvm-dev/2018-November/127408.html.

Differential Revision: https://reviews.llvm.org/D54034
Patch by Luís Marques.

llvm-svn: 346034

Attempt to fix 'logical operation on address of string constant'

Caused a lot of warnings for Windows:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/21178/steps/build/logs/warnings%20%2867%29

llvm-svn: 346033

[X86][AVX512] Change mask ops on vpermi2var tests to not use zeroinitializer.

This is necessary as I'm wanting to remove the 'Constant Pool' shuffle decoding from getTargetShuffleMask - but using getTargetShuffleMaskIndices allows the shuffle combiner to realize that these calls are really broadcasts.....

As with a lot of the X86ISD::VPERMV3 code this causes some vperm2i/vperm2t shuffles to flip depending on optimal commutation.

llvm-svn: 346032

[WebAssembly] Change indices types to unsined int (NFC)

Summary:
This changes int types to unsigned int in a few places: function indices
and `wasm::Valtype` (which is unsigend int enum).  Currently these
values cannot have negative values anyway, so this should not be a
functional change for now.

Reviewers: sbc100

Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 346031

[PowerPC]Disable randomized address space on Linux ppc64le

Recent versions of Ubuntu (17.04 and 18.04) on PowerPC have introduced changes
to Address Space Layout Randomization (ASLR) that is causing 500+ sanitizer
failures. This patch disables ASLR when running the sanitizers on PowerPC 64bit
LE.

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

llvm-svn: 346030

[WebAssembly] Fix bugs in rethrow depth counting and InstPrinter

Summary:
EH stack depth is incremented at `try` and decremented at `catch`. When
there are more than two catch instructions for a try instruction, we
shouldn't count non-first catches when calculating EH stack depths.

This patch fixes two bugs:
- CFGStackify: Exclude `catch_all` in the terminate catch pad when
  calculating EH pad stack, because when we have multiple catches for a
  try we should count only the first catch instruction when calculating
  EH pad stack.
- InstPrinter: The initial intention was also to exclude non-first
  catches, but it didn't account nested try-catches, so it failed on
  this case:
```
try
  try
  catch
  end
catch    <-- (1)
end
```
In the example, when we are at the catch (1), the last seen EH
instruction is not `try` but `end_try`, violating the wrong assumption.

We don't need these after we switch to the second proposal because there
is gonna be only one `catch` instruction. But anyway before then these
bugfixes are necessary for keep trunk in working state.

Reviewers: dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 346029

[analyzer] Fixup of the module build after https://reviews.llvm.org/D53277

Adds AnalyzerOptions.def to the list of textual headers.

llvm-svn: 346028

[DebugInfo][InstMerge] Fix -debugify for phi node created by -mldst-motion

Summary:
-mldst-motion creates a new phi node without any debug info. Use the merged debug location from the incoming stores to fix this.

Fixes PR38177. The test case here is (somewhat) simplified from:

```
struct S {
  int foo;
  void fn(int bar);
};
void S::fn(int bar) {
  if (bar)
    foo = 1;
  else
    foo = 0;
}
```

Reviewers: dblaikie, gbedwell, aprantl, vsk

Reviewed By: vsk

Subscribers: vsk, JDevlieghere, llvm-commits

Tags: #debug-info

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

llvm-svn: 346027

ARMExpandPseudoInsts: Fix CMP_SWAP expansion adding a kill flag to a def

llvm-svn: 346026

[ValueTracking] add test for non-canonical shuffle; NFC

llvm-svn: 346025

[COFF, ARM64] Change setjmp for AArch64 Windows to use Intrinsic.sponentry

Summary: ARM64 setjmp expects sp on entry instead of framepointer.

Patch by: Yin Ma (yinma@codeaurora.org)

Reviewers: mgrang, eli.friedman, ssijaric, mstorsjo, rnk, compnerd

Reviewed By: mgrang

Subscribers: efriedma, javed.absar, kristof.beyls, chrib, cfe-commits

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

llvm-svn: 346024

Fix a few small issues in llvm-pdbutil

Running "llvm-pdbutil dump -all" on linux (using the native PDB reader),
over a few PDBs pulled from the Microsoft public symbol store uncovered
a few small issues:

- stripped PDBs might not have the strings stream (/names)
- stripped PDBs might not have the "module info" stream

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

llvm-svn: 346010

[SystemZ::TTI]  Improve cost handling of uint/sint to fp conversions.

Let i8/i16 uint/sint to fp conversions cost 1 if operand is a load.

Since the load already does the extension, there is no extra cost (previously
returned 2).

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

llvm-svn: 346009

Refactor the lit configuration files

A year or so ago, I re-wrote most of the lit infrastructure in LLVM so
that it wasn't so boilerplate-y. I added lots of common helper type
stuff, simplifed usage patterns, and made the code more elegant and
maintainable.

We migrated to this in LLVM, clang, and lld's lit files, but not in
LLDBs. This started to bite me recently, as the 4 most recent times I
tried to run the lit test suite in LLDB on a fresh checkout the first
thing that would happen is that python would just start crashing with
unhelpful backtraces and I would have to spend time investigating.

You can reproduce this today by doing a fresh cmake generation, doing
ninja lldb and then python bin/llvm-lit.py -sv ~/lldb/lit/SymbolFile at
which point you'll get a segfault that tells you nothing about what your
problem is.

I started trying to fix the issues with bandaids, but it became clear
that the proper solution was to just bring in the work I did in the rest
of the projects. The side benefit of this is that the lit configuration
files become much cleaner and more understandable as a result.

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

llvm-svn: 346008

Reland "Change  the timestamp of llvmcache-foo file to meet the thinLTO prune policy"

Summary:
It is difficult to touch a file with a relative mtime across different OSes as POSIX touch -d is rigid. While we may construct relative timestamps with `date`, POSIX date is inadequate to do so as various OSes' date do not agree on a common format (OpenBSD uses `date -r seconds`, FreeBSD uses `date -v-2M` while GNU accepts `-d '-2 min'`)

Just use python os.utime()

Original description:

    The case may randomly fail if we test it with command "
     while llvm-lit tools/lld/test/ELF/lto/cache.ll; do true; done". It is because the llvmcache-foo file is younger than llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6. But due to timestamp precision reason their timestamp is the same. Given the same timestamp, the file prune policy is to remove bigger size file first, so mostly foo file is removed for its bigger size. And the files size is under threshold after deleting foo file. That's what test case expect.

    However sometimes, the precision is enough to measure that timestamp of llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are smaller than foo, so llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are deleted first. Since the files size is still above the file size threshold after deleting the 2 files, the foo file is also deleted. And then the test case fails, because it expect only one file should be deleted instead of 3.

    The fix is to change the timestamp of llvmcache-foo file to meet the thinLTO prune policy.
    The same fix is applied to llvm code at https://reviews.llvm.org/D52452.

    Patch by Luo Yuanke.

Reviewers: ruiu, craig.topper, smaslov, Jianping, espindola, LuoYuanke, tejohnson

Reviewed By: tejohnson

Subscribers: sbc100, krytarowski, aheejin, llvm-commits, dexonsmith, steven_wu, arichardson, inglorion, emaste, bjope, rupprecht

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

llvm-svn: 346006

[ProfileSummary] Add options to override hot and cold count thresholds.

Summary:
The hot and cold count thresholds are derived from the summary, but for
debugging purposes it is convenient to provide the actual thresholds.

Reviewers: davidxl

Subscribers: llvm-commits

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

llvm-svn: 346005