llvm-svn: 346060

llvm-svn: 346059

llvm-svn: 346058

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

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

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

llvm-svn: 346054

<rdar://problem/44809176>

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

llvm-svn: 346053

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

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

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

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

rdar://problem/45642490

llvm-svn: 346048

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

This change was accidentally missed from the original changeset.

llvm-svn: 346046

It broke MacOS buildbots.

llvm-svn: 346045

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

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

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

llvm-svn: 346040

llvm-svn: 346039

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

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

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

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

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

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

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

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

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

Adds AnalyzerOptions.def to the list of textual headers.

llvm-svn: 346028

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

llvm-svn: 346026

llvm-svn: 346025

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

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

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

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

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