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

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

We need to handle the ConstantAggregateZero case here too.

rdar://45691981

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

llvm-svn: 346004

This is no longer relevant with the new way we initialize the
FileSystem.

llvm-svn: 346003

This moves the abstraction around ::open into the FileSystem, as is
already the case for ::fopen.

llvm-svn: 346002

Change -fsanitize-address-poison-class-member-array-new-cookie to -fsanitize-address-poison-custom-array-cookie

Handle it in the driver and propagate it to cc1

Reviewers: rjmccall, kcc, rsmith

Subscribers: cfe-commits

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

llvm-svn: 346001

Patch by KOLANICH

llvm-svn: 346000

Model this function more closely after the BasicTTIImpl version, with
separate handling of loads and stores. For loads, the set of actually loaded
vectors is checked.

This makes it more readable and just slightly more accurate generally.

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

llvm-svn: 345998

So hopefully windows won't complain.

llvm-svn: 345997

As reported in PR38952, postra-machine-sink relies on DBG_VALUE insns being
adjacent to the def of the register that they reference. This is not always
true, leading to register copies being sunk but not the associated DBG_VALUEs,
which gives the debugger a bad variable location.

This patch collects DBG_VALUEs as we walk through a BB looking for copies to
sink, then passes them down to performSink. Compile-time impact should be
negligable.

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

llvm-svn: 345996

r345961 introduced a path check in
.\tools\clang\tools\extra\test\clang-tidy\clang-tidy-run-with-database.cpp.

r345961 added a check line for a path that only handled / on unix
machines and not \ on windows machines.

This patch handles both cases.

Patch by TWeaver.

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

llvm-svn: 345995

llvm-svn: 345993

*OI++ = *II++ is on line 670, not 668

llvm-svn: 345992

Coalesced memory access requires use of the new function
`__kmpc_data_sharing_coalesced_push_stack` instead of the
`__kmpc_data_sharing_push_stack`.

llvm-svn: 345991

Interestingly, this many year old (when I last looked I remember 2010ish)
checker was committed without any tests, so I thought I'd implement them, but I
was shocked to see how I barely managed to get it working. The code is severely
outdated, I'm not even sure it has ever been used, so I'd propose to move it
back into alpha, and possibly even remove it.

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

llvm-svn: 345990

A new -cc1 flag is avaible for the said purpose: -analyzer-config-help

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

llvm-svn: 345989

This possibility is noted in D53987 for a different case,
so we need to adjust the existing code.

llvm-svn: 345988

llvm-svn: 345987

I'm in the process of refactoring AnalyzerOptions. The main motivation behind
here is to emit warnings if an invalid -analyzer-config option is given from the
command line, and be able to list them all.

In this patch, I'm moving all analyzer options to a def file, and move 2 enums
to global namespace.

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

llvm-svn: 345986

I'm in the process of refactoring AnalyzerOptions. The main motivation behind
here is to emit warnings if an invalid -analyzer-config option is given from
the command line, and be able to list them all.

In this patch, I found some flags that should've been used as checker options,
or have absolutely no mention of in AnalyzerOptions, or are nonexistent.

- NonLocalizedStringChecker now uses its "AggressiveReport" flag as a checker
    option
- lib/StaticAnalyzer/Frontend/ModelInjector.cpp now accesses the "model-path"
    option through a getter in AnalyzerOptions
- -analyzer-config path-diagnostics-alternate=false is not a thing, I removed it,
- lib/StaticAnalyzer/Checkers/AllocationDiagnostics.cpp and
    lib/StaticAnalyzer/Checkers/AllocationDiagnostics.h are weird, they actually
    only contain an option getter. I deleted them, and fixed RetainCountChecker
    to get it's "leak-diagnostics-reference-allocation" option as a checker option,
- "region-store-small-struct-limit" has a proper getter now.

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

llvm-svn: 345985

llvm-svn: 345984

[NFC] Refactor initialisation of Darwin malloc zone fields into separate function called `InitMallocZoneFields()` which is now called from `ReplaceSystemMalloc()`.

Summary:
The motivation here is to be able support initialisation of the
malloc zone on other code paths.

rdar://problem/45284065

Reviewers: kubamracek, george.karpenkov

Subscribers: llvm-commits, #sanitizers

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

llvm-svn: 345983

The previously used combination `PTR_AND_OBJ | PRIVATE` could be used for mapping of some data in Fortran. Changed it to `PTR_AND_OBJ | LITERAL`.

llvm-svn: 345982

Summary:
The previously used combination `PTR_AND_OBJ | PRIVATE` could be used
for mapping of some data in Fortran. Changed it to `PTR_AND_OBJ |
  LITERAL`.

Reviewers: gtbercea

Subscribers: guansong, caomhin, openmp-commits

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

llvm-svn: 345981

This reverts commit r345977.

A few bots failing because the invocation of "touch" is not accepted on
a couple other OSes. Specifically the -d argument is not accepted or requires
a different format.

http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/27103/steps/test_lld/logs/stdio
http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/24974/steps/test_lld/logs/stdio

llvm-svn: 345980

llvm-svn: 345979

target/teams/distribute regions.

Target/teams/distribute regions exist for all the time the kernel is
executed. Thus, if the variable is declared in their context and then
escape it, we can allocate global memory statically instead of
allocating it dynamically.
Patch captures all the globalized variables in target/teams/distribute
contexts, merges them into the records, one per each target region.
Those records are then joined into the union, one per compilation unit
(to save the global memory). Those units are organized into
2 x dimensional arrays, where the first dimension is
the number of blocks per SM and the second one is the number of SMs.
Runtime functions manage this global memory space between the executing
teams.

llvm-svn: 345978

Summary:

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

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

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

llvm-svn: 345977

Summary:
Current globalization scheme works correctly only for SPMD+lightweight
runtime mode and does not work for full runtime. Patch improves support
for the globalization scheme + reduces global memory consumption in
  lightweight runtime mode.
Patch adds runtime functions to work with the statically allocated
global memory. It allows to improve performance and memory consumption.
This global memory must be allocated by the compiler.

Reviewers: grokos, kkwli0, gtbercea, caomhin

Subscribers: guansong, jfb, openmp-commits

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

llvm-svn: 345976

Small-data (i.e. GP-relative) loads and stores allow 16-bit scaled
offset. For a load of a value of type T, the small-data area is
equivalent to an array "T sdata[65536]". This implies that objects
of smaller sizes need to be closer to the beginning of sdata,
while larger objects may be farther away, or otherwise the offset
may be insufficient to reach it. Similarly, an object of a larger
size should not be accessed via a load of a smaller size.

llvm-svn: 345975

Summary:
This patch fixes the NativePDB tests to make them work from x86 command line too

Reviewers: zturner, stella.stamenova

Subscribers: aleksandr.urakov, teemperor, lldb-commits

Tags: #lldb

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

llvm-svn: 345974

Summary:
This allows customizing the flags used when no compile database is
available. It addresses some uses of the old extraFlags extension.

Reviewers: ilya-biryukov

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

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

llvm-svn: 345973