[Dominators] Teach LoopDeletion to use the new incremental API

Summary:
This patch makes LoopDeletion use the incremental DominatorTree API.

We modify LoopDeletion to perform the deletion in 5 steps:
1. Create a new dummy edge from the preheader to the exit, by adding a conditional branch.
2. Inform the DomTree about the new edge.
3. Remove the conditional branch and replace it with an unconditional edge to the exit. This removes the edge to the loop header, making it unreachable.
4. Inform the DomTree about the deleted edge.
5. Remove the unreachable block from the function.

Creating the dummy conditional branch is necessary to perform incremental DomTree update.
We should consider using the batch updater when it's ready.

Reviewers: dberlin, davide, grosser, sanjoy

Reviewed By: dberlin, grosser

Subscribers: mzolotukhin, llvm-commits

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

llvm-svn: 309850

[StackColoring] Update AliasAnalysis information in stack coloring pass (part 2)

This patch is update after the first patch (https://reviews.llvm.org/rL309651) based on the post-commit comments.

Stack coloring pass need to maintain AliasAnalysis information when merging stack slots of different types.
Actually, there is a FIXME comment in StackColoring.cpp

// FIXME: In order to enable the use of TBAA when using AA in CodeGen,
// we'll also need to update the TBAA nodes in MMOs with values
// derived from the merged allocas.

But, TBAA has been already enabled in CodeGen without fixing this pass.
The incorrect TBAA metadata results in recent failures in bootstrap test on ppc64le (PR33928) by allowing unsafe instruction scheduling.
Although we observed the problem on ppc64le, this is a platform neutral issue.

This patch makes the stack coloring pass maintains AliasAnalysis information when merging multiple stack slots.

This patch fixes PR33928.

llvm-svn: 309849

This ppc64 implementation of clear_cache works for both big and little endian.

llvm-svn: 309848

[ubsan] Test -fsanitize=vptr without -fsanitize=null

This reverts commit r309042, thereby adding a test for -fsanitize=vptr
functionality without -fsanitize=null. It also removes -fsanitize=null
from another -fsanitize=vptr test.

llvm-svn: 309847

[ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't available

In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I
did not see the need for the two checks to have separate null checking logic
for the same pointer. I expected the two checks to either always be enabled
together, or to be mutually compatible.

In the mailing list discussion re: r309007 it became clear that that isn't the
case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean,
it's useful to have -fsanitize=vptr emit its own null check. That's what this
patch does: with it, -fsanitize=vptr can be used without -fsanitize=null.

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

llvm-svn: 309846

Fix code format on r309826

Summary:
Fix code format on r309826 / D35458

Reviewers: grosser, bollu

Reviewed By: grosser

Subscribers: pollydev

Tags: #polly

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

llvm-svn: 309845

Revert "Xray docs with description of Flight Data Recorder binary format."

This reverts commit 3462b8ad41a840fd54dbbd0d3f2a514c5ad6f656.

The docs-llvm-html target failed.

llvm-svn: 309842

[AsmParser][GAS-compatibility] Ignore an empty 'p2align' directive

GAS ignores the aforementioned issue
this patch aligns LLVM + throws in an appropriate warning

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

llvm-svn: 309841

Use more consistent names

Reviewing another change I noticed that we use "getSymbols" to mean
different things in different files. Depending on the file it can
return

ArrayRef<StringRef>
ArrayRef<SymbolBody*>
ArrayRef<Symbol*>
ArrayRef<Elf_Sym>

With this change it always returns an ArrayRef<SymbolBody*>. The other
functions are renamed getELFsyms() and getSymbolNames().

Note that we cannot return ArrayRef<Symbol*> instead of
ArreyRef<SymbolBody*> because local symbols have a SymbolBody but not
a Symbol.

llvm-svn: 309840

[InstCombine] Add missing test case for (xor (sext (cmp)), -1) -> (sext (!cmp)).

llvm-svn: 309839

Fix PR33727: std::basic_stringbuf only works with DefaultConstructible allocators. Thanks to Jonathan Wakely for the report and suggested fix

llvm-svn: 309838

Xray docs with description of Flight Data Recorder binary format.

Summary:
Adding a new restructuredText file to document the trace format produced with
an FDR mode handler and read by llvm-xray toolset.

Reviewers: dberris, pelikan

Subscribers: llvm-commits

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

llvm-svn: 309836

Fix r309826: Move intantiation and specialization of OwningScopAnalysisManagerFunctionProxy to the polly namespace.

When compiling with clang, explicit instantiation of the
OwningScopAnalysisManagerFunctionProxy needs to happen within the polly
namespace. Same goes with the specialization of its run method.

llvm-svn: 309835

Assert that the offset of a DBG_VALUE is always 0. (NFC)

llvm-svn: 309834

Revert "[lit] Avoid copying llvm/utils/lit/tests/Inputs with lit site configs"

This reverts r309602, check-lit still leaves Output directories in the
source directory.

llvm-svn: 309833

AMDGPU: Restore using MRI to find highest used regs

If there are no calls, this is a faster path than
searching the entire program for calls.

This was supposed to be left in r309781.
Fixes unused variable warning.

llvm-svn: 309832

Remove the unused Offset field from MachineLocation (NFC)

rdar://problem/33580047

llvm-svn: 309831

[DAG] Improve candidate pruning in store merge failure case. NFCI

During store merge we construct a sorted list of consecutive store
candidates and consider subsequences for merging into a single
store. For each subsequence we check if the stored value type is legal
the merged store would have valid and fast and if the constructed
value to be stored is valid. The only properties that affect this
check between subsequences is the size of the subsequence, the
alignment of the first store, the alignment of the stored load value
(when merging stores-of-loads), and whether the merged value is a
constant zero.

If we do not find a viable mergeable subsequence starting from the
first store of length N, we know that a subsequence starting at a
later store of length N will also fail unless the new store's
alignment, the new load's alignment (if we're merging store-of-loads),
or we've dropped stores of nonzero value and could construct a merged
stores of zero (for merging constants).

As a result if we fail to find a valid subsequence starting from the
first store we can safely skip considering subsequences that start
with subsequent stores unless one of the above properties is
true. This significantly (2x) improves compile time in some
pathological cases.

Reviewers: RKSimon, efriedma, zvi, spatel, waltl

Subscribers: grandinj, llvm-commits

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

llvm-svn: 309830

[ELF] When the code segment is the last, align it to the page boundary

When the data segment is the last segment, it is correct to leave
it unaligned. However, when the code segment is the last segment,
it should be aligned to the page boundary to avoid loading the
non-segment parts of the ELF file at the end of the file.

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

llvm-svn: 309829

[Polly][PM][WIP] Polly pass registration

Summary:
This patch is a first attempt at registering Polly passes with the LLVM tools. Tool plugins are still unsupported, but this registration is usable from the tools if Polly is linked into them (albeit requiring minimal patches to those tools). Registration requires a small amount of machinery (the owning analysis proxies), necessary for injecting ScopAnalysisManager objects into the calling tools.

This patch is marked WIP because the registration is incomplete. Parsing manual pipelines is fully supported, but default pass injection into the O3 pipeline is lacking, mostly because there is opportunity for some redesign here, I believe. The first point of order would be insertion points. I think it makes sense to run before the vectorizers. Running Polly Early, however, is weird. Mostly because it actually is the default (which to me is unexpected), and because Polly runs it's own O1 pipeline. Why not instead insert it at an appropriate place somewhere after simplification happend? Running after the loop optimizers seems intuitive, but it also seems wasteful, since multiple consecutive loops might well be a single scop, and we don't need to run for all of them.

My second request for comments would be regarding all those smallish helper passes we have,  like PollyViewer, PollyPrinter, PollyImportJScop. Right now these are controlled by command line options, deciding whether they should be part of the Polly pipeline. What is your opinion on treating them like real passes, and have the user write an appropriate pipeline if they want to use any of them?

Reviewers: grosser, Meinersbur, bollu

Reviewed By: grosser

Subscribers: llvm-commits, pollydev

Tags: #polly

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

llvm-svn: 309826

[AArch64] Improve the test of conditional branch fusion

Separate the checking of the fused pairings with B.cc and CBcc.

llvm-svn: 309825

Remove unused includes of MachineLocation.h (NFC)

llvm-svn: 309824

Remove unreachable code. (NFC)

MachineLocation::getOffset() always returns 0.

rdar://problem/33580047

llvm-svn: 309823

Remove debug metadata from copied instruction to prevent GPUModule verification failure

Summary:
**Remove debug metadata from instruction to be copied to prevent the source file's debug metadata being copied into GPUModule and eventually failing Module verification and ASM string codegeneration.**

When copying the instruction onto the Module meant for the GPU, debug metadata attached to an instruction causes all related metadata to be pulled into the Module, including the DICompileUnit, which is not listed in llvm.dbg.cu of the Module. This fails the verification of the Module and generation of the ASM string.

The only debug metadata of the instruction, the DebugLoc, is unset by this patch.

This patch reattempts https://reviews.llvm.org/D35630 by targeting only those instructions that are to end up in a Module meant for the GPU.

Reviewers: grosser, bollu

Reviewed By: grosser

Subscribers: pollydev

Tags: #polly

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

llvm-svn: 309822

[AArch64] Simplify AES*Tied pseudo expansion (NFC).

Summary:
Suggested by @t.p.northover in https://bugs.llvm.org/show_bug.cgi?id=34015.

Reviewers: javed.absar, t.p.northover, rengolin

Reviewed By: t.p.northover

Subscribers: aemerson, kristof.beyls, llvm-commits, t.p.northover

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

llvm-svn: 309821

configure.py: Make python3 friendly

mostly prints and exceptions.
Few behavioral changes are documented in the text
Generated Makefile is identical between python2 and python3

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

[InlineCost] Remove redundant call. NFC.

llvm-svn: 309819

Assert that the offset in MachineLocation::set() is always 0. (NFC)

llvm-svn: 309818

[InlineCost] Simplify more 'and' and 'or' operations.

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

llvm-svn: 309817

[SLPVectorizer] Generalize interface of functions, NFC.

llvm-svn: 309816

Define _GNU_SOURCE for RTEMS c++

Summary: This is required by the libc++ locale support.

Reviewers: jyknight

Subscribers: fedor.sergeev

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

llvm-svn: 309815

[SLPVectorizer] Test update, NFC.

llvm-svn: 309814

[rename] NFC, extract symbol canonicalization logic into function

This function will be used by the clang-refactor's rename actions

llvm-svn: 309813

[SLP] Fix for PR31880: shuffle and vectorize repeated scalar ops on extracted elements

Summary:
Currently most of the time vectors of extractelement instructions are
treated as scalars that must be gathered into vectors. But in some
cases, like when we have extractelement instructions from single vector
with different constant indeces or from 2 vectors of the same size, we
can treat this operations as shuffle of a single vector or blending of 2
vectors.
```
define <2 x i8> @g(<2 x i8> %x, <2 x i8> %y) {
  %x0 = extractelement <2 x i8> %x, i32 0
  %y1 = extractelement <2 x i8> %y, i32 1
  %x0x0 = mul i8 %x0, %x0
  %y1y1 = mul i8 %y1, %y1
  %ins1 = insertelement <2 x i8> undef, i8 %x0x0, i32 0
  %ins2 = insertelement <2 x i8> %ins1, i8 %y1y1, i32 1
  ret <2 x i8> %ins2
}
```
can be converted to something like
```
define <2 x i8> @g(<2 x i8> %x, <2 x i8> %y) {
  %1 = shufflevector <2 x i8> %x, <2 x i8> %y, <2 x i32> <i32 0, i32 3>
  %2 = mul <2 x i8> %1, %1
  ret <2 x i8> %2
}
```
Currently this type of conversion is considered as high cost
transformation.

Reviewers: mzolotukhin, delena, mkuper, hfinkel, RKSimon

Subscribers: ashahid, RKSimon, spatel, llvm-commits

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

llvm-svn: 309812

[PM] Fix proxy invalidation

Summary: I made a mistake in handling transitive invalidation of analysis results. I've updated the list of preserved analyses as well as the correct result dependences.

The Invalidator passed through the invalidate() path can be used to
transitively invalidate analyses. It frequently happens that analysis
results depend on other analyses, and thus store references to their
results. When the dependee now gets invalidated, the depender needs to
be invalidated as well. This is the purpose of the Invalidator object,
which can be used to check whether some dependee analysis is in the
process of being invalidated. I originally was checking the wrong
dependee analyses, which is an actual error, you can only check analysis
results that are in the cache (which they are if you've captured their
reference). The invalidation I'm handling inside the proxy deals with
the standard analyses the proxy passes into the Scop pipeline, since I'm
capturing their reference.

This checking allows us to actually preserve a couple of results outside
of the proxy, since the Scop pipeline shouldn't break those, or
otherwise should update them accordingly.

Reviewers: grosser, Meinersbur, bollu

Reviewed By: grosser

Subscribers: pollydev, llvm-commits

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

llvm-svn: 309811

Adapt clang-tidy checks to changing semantics of hasDeclaration.

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

llvm-svn: 309810

Unify and simplify the behavior of the hasDeclaration matcher.

Originally, we weren't able to match on Type nodes themselves (only QualType),
so the hasDeclaration matcher was initially written to give what we thought are
reasonable results for QualType matches.

When we chagned the matchers to allow matching on Type nodes, it turned out
that the hasDeclaration matcher was by chance written templated enough to now
allow hasDeclaration to also match on (some) Type nodes.

This patch change the hasDeclaration matcher to:
a) work the same on Type and QualType nodes,
b) be completely explicit about what nodes we can match instead of just allowing
   anything with a getDecl() to match,
c) explicitly control desugaring only one level in very specific instances.
d) adds hasSpecializedTemplate and tagType matchers to allow migrating
  existing use cases that now need more explicit matchers

Note: This patch breaks clang-tools-extra. The corresponding patch there
is approved and will land in a subsequent patch.

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

llvm-svn: 309809

[GPUJIT] Add GPUJIT APIs for allocating and freeing managed memory.

We introduce `polly_mallocManaged` and `polly_freeManaged` as
proxies for `cudaMallocManaged` / `cudaFree`. This is currently not
used by Polly. It is auxiliary code that is used in `COSMO`.

This is useful because `polly_mallocManaged` matches the signature of `malloc`,
while `cudaMallocManaged` does not. We introduce `polly_freeManaged` for
symmetry.

We use this in COSMO to use the unified memory feature of the newer
CUDA APIs (>= 6).

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

llvm-svn: 309808

[SI][NewPM] Collect loop count statistics

llvm-svn: 309807

[MIR] Print target-specific constant pools

This should enable us to test the generation of target-specific constant
pools, e.g. for ARM:

constants:
 - id:              0
   value:           'g(GOT_PREL)-(LPC0+8-.)'
   alignment:       4
   isTargetSpecific: true

I intend to use this to test PIC support in GlobalISel for ARM.

This is difficult to test outside of that context, since the existing
MIR tests usually rely on parser support as well, and that seems a bit
trickier to add. We could try to add a unit test, but the setup for that
seems rather convoluted and overkill.

We do test however that the parser reports a nice error when
encountering a target-specific constant pool.

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

llvm-svn: 309806

[SD] Set PollyUseRuntimeAliasChecks correctly

llvm-svn: 309805

[globalisel][tablegen] Do not merge memoperands from instructions that weren't in the match.

Summary:
Fix a bug discovered in an out-of-tree target where memoperands from
pseudo-instructions that weren't part of the match were being merged into the
result instructions as part of GIR_MergeMemOperands.

This bug was caused by a change to the handling of State.MIs between rules when
the state machine tables were fused into a single table. Previously, each rule
would reset State.MIs using State.MIs.resize(1) but this is no longer done, as a
result stale data is occasionally left in some elements of State.MIs. Most
opcodes aren't affected by this but GIR_MergeMemOperands merges all memoperands
from the intructions recorded in State.MIs into the result instruction.

Suppose for example, we processed but rejected the following pattern:
  (signextend (load x))
at this point, State.MIs contains the signextend and the load. Now suppose we
process and accept this pattern:
  (add x, y)
at this point, State.MIs contains the add as well as the (now irrelevant) load.
When GIR_MergeMemOperands is processed, the memoperands from that irrelevant
load will be merged into the result instruction even though it was not part of
the match.

Bringing back the State.MIs.resize(1) would fix the problem but it would limit
our ability to optimize the table in the future. Instead, this patch fixes the
problem by explicitly stating which instructions should be merged into the result.

There's no direct test case in this commit because a test case would be very brittle.
However, at the time of writing this should fix the failures in
http://green.lab.llvm.org/green/job/Compiler_Verifiers_GlobalISEL/ as well as a
failure in test/CodeGen/ARM/GlobalISel/arm-isel.ll when expensive checks are enabled.

Reviewers: ab, t.p.northover, qcolombet, rovka, aditya_nandakumar

Subscribers: fhahn, kristof.beyls, igorb, llvm-commits

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

llvm-svn: 309804

Fix ProcessAPITestCase.test_get_process_info

llvm-svn: 309803

[GPUJIT] Teach GPUJIT to use a pre-existing CUDA context if available.

On mixing the driver and runtime APIs, it is quite possible that a
context already exists due to runtime API usage. In this case, Polly should
try to use the same context.

This patch teaches GPUJIT to detect that a context exists and how to
pick up this context.

Without this, calling `cudaMallocManaged`, for example, before a
polly-generated kernel launch causes P100 to *hang*.

This is a part of (https://reviews.llvm.org/D35991) that was extracted
out.

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

llvm-svn: 309802

[clangd] Run clang-format on all clangd sources. NFC.

llvm-svn: 309801

[clangd] Capitalized descriptions of clangd options. NFC.

To follow the style of other options shown on `clangd -help`.

llvm-svn: 309800

[StaticAnalyzer] Fix false positives for unreachable code in macros.

Example:

#define MACRO(C)   if (C) { static int x; .. }
void foo() {
MACRO(0);
}

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

llvm-svn: 309799

[asan] Interceptors for Fuchsia

Summary:
Fuchsia uses the "memintrinsics" interceptors, though not via any
generalized interception mechanism.  It doesn't use any other interceptors.

Submitted on behalf of Roland McGrath.

Reviewers: vitalybuka, alekseyshl, kcc

Reviewed By: vitalybuka

Subscribers: kubamracek, phosek, filcab, llvm-commits

Tags: #sanitizers

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

llvm-svn: 309798

[sanitizer_common] Fuchsia-specific implementation of SanitizerCoverage

Submitted on behalf of Roland McGrath.

Reviewers: kcc, eugenis, alekseyshl, vitalybuka

Reviewed By: kcc

Subscribers: filcab, vitalybuka, phosek, llvm-commits, kubamracek, mgorny

Tags: #sanitizers

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

llvm-svn: 309797

[ELF] - Recommit r309252 "[ELF] - Fix missing relocation when linking executable with --unresolved-symbols=ignore-all"

With fix for undefined weak symbols in executable.

Original commit message:
This is PR32112. Previously when we linked executable with
--unresolved-symbols=ignore-all and undefined symbols, like:

_start:
callq und@PLT

we did not create relocations, though it looks in that case
we should delegate handling of such symbols to runtime linker,
hence should emit them. Patch fixes that.

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

llvm-svn: 309796

Use VFS operations in FileManager::makeAbsolutePath.

Summary: It used to call into llvm::sys::fs::make_absolute.

Reviewers: akyrtzi, erikjv, bkramer, krasimir, klimek

Reviewed By: klimek

Subscribers: cfe-commits

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

llvm-svn: 309795

[Bash-autocompletion] Add comment to test so that it is easier to fix

Summary:
clang/test/Driver/autocomplete.c is a test for --autocomplete, and this
test might break if people add/modify flags or HelpText. So I've add
comment for future developers so that they can fix this file according
to the change they had made.

Reviewers: v.g.vassilev, teemperor, ruiu

Subscribers: cfe-commits

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

llvm-svn: 309794

[InstCombine] Add test cases for 'or' and 'xor' to match the vector 'and' of 'sext' of 'cmp' test.

When the 'and' test was originally added it was intended to make sure we didn't change it to a sext of and of cmp. But since then the test was changed to expect it to be turned into 'select cmp1, sext cmp2, 0'. Then another optimization was added to turn the select into 'sext (and cmp1, cmp2)' which is exactly the transformation that was being blocked when the test case started.

Looks like 'or' gets optimized in a similar way, but not 'xor'.

llvm-svn: 309793

[XRay][compiler-rt] Remove use of std::mutex and std::shared_ptr from global scope.

Summary:
This change attempts to remove all the dependencies we have on
std::mutex and any std::shared_ptr construction in global variables. We
instead use raw pointers to these objects, and construct them on the
heap. In cases where it's possible, we lazily initialize these pointers.

While we do not have a replacement for std::shared_ptr yet in
compiler-rt, we use this work-around to avoid having to statically
initialize the objects as globals. Subsequent changes should allow us to
completely remove our dependency on std::shared_ptr and instead have our
own implementation of the std::shared_ptr and std::weak_ptr semantics
(or completely rewrite the implementaton to not need these
standard-library provided abstractions).

Reviewers: dblaikie, kpw, pelikan

Subscribers: llvm-commits

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

llvm-svn: 309792

[NewGVN] Fold single-use variables. NFCI.

llvm-svn: 309790

[NewGVN] Remove a (now stale) comment. NFCI.

llvm-svn: 309789

Fix the bug that parseAAPipeline is not invoked in runNewPMPasses in release compiler.

Summary: The logic is guarded by "assert".

Reviewers: davidxl, davide, chandlerc

Reviewed By: davide, chandlerc

Subscribers: sanjoy, llvm-commits, mehdi_amini

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

llvm-svn: 309787

[CMake] Include llvm-objcopy tool in Fuchsia toolchain

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

llvm-svn: 309786

[SimplifyCFG] Fix typo in comment. NFC

llvm-svn: 309785

[PM] Fix a bug where through CGSCC iteration we can get
infinite-inlining across multiple runs of the inliner by keeping a tiny
history of internal-to-SCC inlining decisions.

This is still a bit gross, but I don't yet have any fundamentally better
ideas and numerous people are blocked on this to use new PM and ThinLTO
together.

The core of the idea is to detect when we are about to do an inline that
has a chance of re-splitting an SCC which we have split before with
a similar inlining step. That is a critical component in the inlining
forming a cycle and so far detects all of the various cyclic patterns
I can come up with as well as the original real-world test case (which
comes from a ThinLTO build of libunwind).

I've added some tests that I think really demonstrate what is going on
here. They are essentially state machines that march the inliner through
various steps of a cycle and check that we stop when the cycle is closed
and that we actually did do inlining to form that cycle.

A lot of thanks go to Eric Christopher and Sanjoy Das for the help
understanding this issue and improving the test cases.

The biggest "yuck" here is the layering issue -- the CGSCC pass manager
is providing somewhat magical state to the inliner for it to use to make
itself converge. This isn't great, but I don't honestly have a lot of
better ideas yet and at least seems nicely isolated.

I have tested this patch, and it doesn't block *any* inlining on the
entire LLVM test suite and SPEC, so it seems sufficiently narrowly
targeted to the issue at hand.

We have come up with hypothetical issues that this patch doesn't cover,
but so far none of them are practical and we don't have a viable
solution yet that covers the hypothetical stuff, so proceeding here in
the interim. Definitely an area that we will be back and revisiting in
the future.

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

llvm-svn: 309784

AMDGPU: Fix clobbering CSR VGPRs when spilling SGPR to it

llvm-svn: 309783

AMDGPU: Fix emitting encoded calls

This was failing on out of bounds access to the extra operands
on the s_swappc_b64 beyond those in the instruction definition.

This was working, but somehow regressed within the past few weeks,
although I don't see any obvious commit.

llvm-svn: 309782

AMDGPU: Analyze callee resource usage in AsmPrinter

llvm-svn: 309781

Update the new PM pipeline to make ICP aware if it is SamplePGO build.

Summary: In ThinLTO backend compile, OPTOptions are not set so that the ICP in ThinLTO backend does not know if it is a SamplePGO build, in which profile count needs to be annotated directly on call instructions. This patch cleaned up the PGOOptions handling logic and passes down PGOOptions to ThinLTO backend.

Reviewers: chandlerc, tejohnson, davidxl

Reviewed By: chandlerc

Subscribers: sanjoy, llvm-commits, mehdi_amini

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

llvm-svn: 309780

[AMDGPU] Fix asan error after last commit

Previous change "Turn s_and_saveexec_b64 into s_and_b64 if
result is unused" introduced asan use-after-poison error.
Instruction was analyzed after eraseFromParent() calls.

Move analysys higher than erase.

llvm-svn: 309779

[Driver] Disable static C++ library support on Fuchsia

Don't support or build static C++ libraries for Fuchsia.

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

llvm-svn: 309778

[DAG] Refactor store merge subexpressions. NFC.

Distribute various expressions across ifs.

llvm-svn: 309777

AMDGPU: Don't place arguments in emergency stack slot

When finding the fixed offsets for function arguments,
this needs to skip over the 4 bytes reserved for the
emergency stack slot.

llvm-svn: 309776

DAG: Undo and->or combine with FrameIndexes

This pattern shows up when lowering byval copies on AMDGPU.

The byval object access is split into 4-byte chunks, adding a
constant offset to the FixedStack base. When some of the offsets
turn into ors, this prevents combining the constant offsets.

This makes it not apparent that the object is there when matching
addressing modes, so it ends up using a scratch wave offset
relative access and the lengthy frame index expansion for that.

llvm-svn: 309775

X86: Do not use llc -march in tests.

`llc -march` is problematic because it only switches the target
architecture, but leaves the operating system unchanged. This
occasionally leads to indeterministic tests because the OS from
LLVM_DEFAULT_TARGET_TRIPLE is used.

However we can simply always use `llc -mtriple` instead. This changes
all the tests to do this to avoid people using -march when they copy and
paste parts of tests.

See also the discussion in https://reviews.llvm.org/D35287

llvm-svn: 309774

Update LiveDebugValues to generate DIExpressions for spill offsets
instead of using the deprecated offset field of DBG_VALUE.

This has no observable effect on the generated DWARF, but the
assembler comments will look different.

rdar://problem/33580047

llvm-svn: 309773

Fix a mis-feature with propagation of breakpoint options -> location options.

When an option was set at on a location, I was just copying the whole option set
to the location, and letting it shadow the breakpoint options.  That was wrong since
it meant changes to unrelated options on the breakpoint would no longer take on this
location.  I added a mask of set options and use that for option propagation.

I also added a "location" property to breakpoints, and added SBBreakpointLocation.{G,S}etCommandLineCommands
since I wanted to use them to write some more test cases.

<rdar://problem/24397798>

llvm-svn: 309772

Revert "Reland "[llvm][llvm-objcopy] Added support for outputting to binary in llvm-objcopy""

This is failing to compile on 32-bit ARM bots.

This reverts commit r309768.

llvm-svn: 309771

Update MIR testcase to reflect change in r309751.

rdar://problem/33580047

llvm-svn: 309769

Reland "[llvm][llvm-objcopy] Added support for outputting to binary in llvm-objcopy"

This change adds the "-O binary" flag which directs llvm-objcopy to
output the object file to the same format as GNU objcopy does when given
the flag "-O binary". This was done by splitting the Object class into
two subclasses ObjectELF and ObjectBianry which each output a different
format but relay on the same code to read in the Object in Object.

Patch by Jake Ehrlich

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

llvm-svn: 309768

[AMDGPU] Turn s_and_saveexec_b64 into s_and_b64 if result is unused

With SI_END_CF elimination for some nested control flow we can now
eliminate saved exec register completely by turning a saveexec version
of instruction into just a logical instruction.

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

llvm-svn: 309766

Remove unused accessor (NFC)

rdar://problem/33580047

llvm-svn: 309763

[AMDGPU] Collapse adjacent SI_END_CF

Add a pass to remove redundant S_OR_B64 instructions enabling lanes in
the exec. If two SI_END_CF (lowered as S_OR_B64) come together without any
vector instructions between them we can only keep outer SI_END_CF, given
that CFG is structured and exec bits of the outer end statement are always
not less than exec bit of the inner one.

This needs to be done before the RA to eliminate saved exec bits registers
but after register coalescer to have no vector registers copies in between
of different end cf statements.

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

llvm-svn: 309762

Assert that the offset of a MachineLocation is always 0.
This is to convince me that it may safely be removed in a follow-up commit.

rdar://problem/33580047

llvm-svn: 309761

[sanitizer_common] Fuchsia-specific symbolizer

Summary:
Fuchsia doesn't support built-in symbolization per se at all.
Instead, it always emits a Fuchsia-standard "symbolizer markup"
format that makes it possible for a post-processing filter to
massage the logs into symbolized format.  Hence, it does not
support user-specified formatting options for backtraces or other
symbolization.

Reviewers: vitalybuka, alekseyshl, kcc

Subscribers: kubamracek, mgorny, phosek, filcab, llvm-commits

Tags: #sanitizers

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

llvm-svn: 309760

[SCEV/IndVars] Always compute loop exiting values if the backedge count is 0

If SCEV can prove that the backedge taken count for a loop is zero, it does not
need to "understand" a recursive PHI to compute its exiting value.

This should fix PR33885.

llvm-svn: 309758

Use helper function instead of manually constructing DBG_VALUEs (NFC)

rdar://problem/33580047

llvm-svn: 309757

[sanitizer_common] Fuchsia OS support code

Submitted on behalf of Roland McGrath.

Reviewers: vitalybuka, alekseyshl, kcc

Reviewed By: vitalybuka

Subscribers: cryptoad, srhines, kubamracek, mgorny, phosek, filcab, llvm-commits

Tags: #sanitizers

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

llvm-svn: 309756

ARM: Do not use llc -march in tests.

`llc -march` is problematic because it only switches the target
architecture, but leaves the operating system unchanged. This
occasionally leads to indeterministic tests because the OS from
LLVM_DEFAULT_TARGET_TRIPLE is used.

However we can simply always use `llc -mtriple` instead. This changes
all the tests to do this to avoid people using -march when they copy and
paste parts of tests.

See also the discussion in https://reviews.llvm.org/D35287

llvm-svn: 309755

PowerPC: Do not use llc -march in tests.

`llc -march` is problematic because it only switches the target
architecture, but leaves the operating system unchanged. This
occasionally leads to indeterministic tests because the OS from
LLVM_DEFAULT_TARGET_TRIPLE is used.

However we can simply always use `llc -mtriple` instead. This changes
all the tests to do this to avoid people using -march when they copy and
paste parts of tests.

This patch:
- Removes -march if the .ll file already has a matching `target triple`
  directive or -mtriple argument.
- In all other cases changes -march=ppc32/-march=ppc64 to
  -mtriple=ppc32--/-mtriple=ppc64--

See also the discussion in https://reviews.llvm.org/D35287

llvm-svn: 309754

[ForwardOpTree] Execute canForwardTree also in release builds.

Commit r309730 moved the call to canForwardTree into an assert(), even
though this function has side-effects if its DoIt parameter is true. To
avoid a warning in release builds, do an (void)Execution of its result
instead.

To avoid such confusion in the future, rename
canForwardTree() to forwardTree().

llvm-svn: 309753

[Headers][Darwin] Allow #include_next<float.h> to work on Darwin prior to 10.7

This fixes PR31504 and it's a follow up from adding #include_next<float.h>
for Darwin in r289018.

rdar://problem/29856682

llvm-svn: 309752

Remove PrologEpilogInserter's usage of DBG_VALUE's offset field

In the last half-dozen commits to LLVM I removed code that became dead
after removing the offset parameter from llvm.dbg.value gradually
proceeding from IR towards the backend. Before I can move on to
DwarfDebug and friends there is one last side-called offset I need to
remove:  This patch modifies PrologEpilogInserter's use of the
DBG_VALUE's offset argument to use a DIExpression instead. Because the
PrologEpilogInserter runs at the Machine level I had to play a little
trick with a named llvm.dbg.mir node to get the DIExpressions to print
in MIR dumps (which print the llvm::Module followed by the
MachineFunction dump).

I also had to add rudimentary DwarfExpression support to CodeView and
as a side-effect also fixed a bug (CodeViewDebug::collectVariableInfo
was supposed to give up on variables with complex DIExpressions, but
would fail to do so for fragments, which are also modeled as
DIExpressions).

With this last holdover removed we will have only one canonical way of
representing offsets to debug locations which will simplify the code
in DwarfDebug (and future versions of CodeViewDebug once it starts
handling more complex expressions) and make it easier to reason about.

This patch is NFC-ish: All test case changes are for assembler
comments and the binary output does not change.

rdar://problem/33580047
Differential Revision: https://reviews.llvm.org/D36125

llvm-svn: 309751

[clang] Change the condition of unnecessary packed warning

Summary:
Change the condition of this unnecessary packed warning. The packed is unnecessary when
1. the alignment of the struct/class won't alter.
2. the size is unchanged.
3. the offset of each field is the same.

Remove all field-level warning.

Reviewers: chh, akyrtzi, rtrieu

Reviewed By: chh

Subscribers: rsmith, srhines, cfe-commits, xazax.hun

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

llvm-svn: 309750

[sanitizer_common] Disable filesystem-related code for Fuchsia

Summary:
Fuchsia doesn't support filesystem access per se at low level.
So it won't use any of the filesystem-oriented code in sanitizer_common.

Submitted on behalf of Roland McGrath.

Reviewers: vitalybuka, alekseyshl, kcc

Reviewed By: vitalybuka

Subscribers: kubamracek, phosek, filcab, llvm-commits

Tags: #sanitizers

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

llvm-svn: 309749

[AArch64] Fix a typo in isExtFreeImpl()

next => not

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

llvm-svn: 309748

[llvm-cov] Allow specifying distinct architectures for each loaded binary

The coverage tool needs to know which slice to look at when it's handed
a universal binary. Some projects need to look at aggregate coverage
reports for a variety of slices in different binaries: this patch adds
support for these kinds of projects to llvm-cov.

rdar://problem/33579007

llvm-svn: 309747

[Hexagon] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 309746

[sanitizer_common] Fuchsia support for interceptors

Summary:
Actually Fuchsia non-support for interceptors.  Fuchsia doesn't use
interceptors in the common sense at all.  Almost all system library
functions don't need interception at all, because the system
libraries are just themselves compiled with sanitizers enabled and
have specific hook interfaces where needed to inform the sanitizer
runtime about thread lifetimes and the like.  For the few functions
that do get intercepted, they don't use a generic mechanism like
dlsym with RTLD_NEXT to find the underlying system library function.
Instead, they use specific extra symbol names published by the
system library (e.g. __unsanitized_memcpy).

Submitted on behalf of Roland McGrath.

Reviewers: vitalybuka, alekseyshl, kcc, filcab

Reviewed By: filcab

Subscribers: kubamracek, phosek, filcab, llvm-commits

Tags: #sanitizers

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

llvm-svn: 309745

[AArch64] Rewrite stack frame handling for win64 vararg functions

The previous attempt, which made do with a single offset in
computeCalleeSaveRegisterPairs, wasn't quite enough. The previous
attempt only worked as long as CombineSPBump == true (since the
offset would be adjusted later in fixupCalleeSaveRestoreStackOffset).

Instead include the size for the fixed stack area used for win64
varargs in calculations in emitPrologue/emitEpilogue. The stack
consists of mainly three parts;
- AFI->getLocalStackSize()
- AFI->getCalleeSavedStackSize()
- FixedObject

Most of the places in the code which previously used the CSStackSize
now use PrologueSaveSize instead, which is the sum of the latter
two, while some cases which need exactly the middle one use
AFI->getCalleeSavedStackSize() explicitly instead of a local variable.

In addition to moving the offsetting into emitPrologue/emitEpilogue
(which fixes functions with CombineSPBump == false), also set the
frame pointer to point to the right location, where the frame pointer
and link register actually are stored. In addition to the prologue/epilogue,
this also requires changes to resolveFrameIndexReference.

Add tests for a function that keeps a frame pointer and another one
that uses a VLA.

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

llvm-svn: 309744

AMDGPU: Fix handling of div_scale with undef inputs

The src0 register must match src1 or src2, but if these
were undefined they could end up using different implicit_defed
virtual registers. Force these to use one undef vreg or pick the
defined other register.

Also fixes producing invalid nodes without the right number of
inputs when src2 is undef.

llvm-svn: 309743

[ubsan] Enable UBSan build for Fuchsia

Submitted on behalf of Roland McGrath.

Reviewers: vitalybuka, alekseyshl, kcc

Reviewed By: vitalybuka

Subscribers: srhines, kubamracek, mgorny, phosek, filcab, llvm-commits

Tags: #sanitizers

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

llvm-svn: 309742

Fix creating bitcasts with wrong address space

In a future commit AMDGPU will start passing
aggregates directly to more functions, triggering
asserts in test/CodeGenOpenCL/addr-space-struct-arg.cl

llvm-svn: 309741

[DAG] Factor out common expressions. NFC.

llvm-svn: 309740

[Value Tracking] Default argument to true and rename accordingly. NFC.

IMHO this is a bit more readable.

llvm-svn: 309739