Fixes quoting of profile arguments to work on Windows
Suppresses adding profile arguments to linker flags when using lld-link
Avoids -fprofile-instr-use being added to rc.exe flags
Removes duplicated adding of -fprofile-instr-use to linker flags (since
r355541)
Move handling LLVM_PROFDATA_FILE to HandleLLVMOptions.cmake

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

llvm-svn: 372209

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

Change-Id: Ic38f47cb2079c2c1070a441b5943854844d80a7c
llvm-svn: 372208

Summary:
This will allow writing `if(A != llvm::Align::None())` which is clearer than `if(A > llvm::Align(1))`

This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 372207

Reviewers: ilya-biryukov

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

llvm-svn: 372206

This fix allows tsan to report stack traces correctly even in the
presence of mid-stack inlining by the Go compiler.

See https://go-review.googlesource.com/c/go/+/195781 for the Go runtime side of this change.

Author: randall77 (Keith Randall)
Reviewed: https://reviews.llvm.org/D67671
llvm-svn: 372205

This patch fixes a bug exposed by D65653 where a subsequent invocation
of `determineCalleeSaves` ends up with a different size for the callee
save area, leading to different frame-offsets in debug information.

In the invocation by PEI, `determineCalleeSaves` tries to determine
whether it needs to spill an extra callee-saved register to get an
emergency spill slot. To do this, it calls 'estimateStackSize' and
manually adds the size of the callee-saves to this. PEI then allocates
the spill objects for the callee saves and the remaining frame layout
is calculated accordingly.

A second invocation in LiveDebugValues causes estimateStackSize to return
the size of the stack frame including the callee-saves. Given that the
size of the callee-saves is added to this, these callee-saves are counted
twice, which leads `determineCalleeSaves` to believe the stack has
become big enough to require spilling an extra callee-save as emergency
spillslot. It then updates CalleeSavedStackSize with a larger value.

Since CalleeSavedStackSize is used in the calculation of the frame
offset in getFrameIndexReference, this leads to incorrect offsets for
variables/locals when this information is recalculated after PEI.

Reviewers: omjavaid, eli.friedman, thegameg, efriedma

Reviewed By: efriedma

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

llvm-svn: 372204

Summary:
Currently our expression evaluators only prints very basic errors that are not very useful when writing complex expressions.

For example, in the expression below the user made a type error, but it's not clear from the diagnostic what went wrong:
```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: invalid operands to binary expression ('int' and 'double')
```

This patch enables full Clang diagnostics in our expression evaluator. After this patch the diagnostics for the expression look like this:

```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: <user expression 1>:1:54: invalid operands to binary expression ('int' and 'float')
printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
                                               ~~~~~~^~~~
```

To make this possible, we now emulate a user expression file within our diagnostics. This prevents that the user is exposed to
our internal wrapper code we inject.

Note that the diagnostics that refer to declarations from the debug information (e.g. 'note' diagnostics pointing to a called function)
will not be improved by this as they don't have any source locations associated with them, so caret or line printing isn't possible.
We instead just suppress these diagnostics as we already do with warnings as they would otherwise just be a context message
without any context (and the original diagnostic in the user expression should be enough to explain the issue).

Fixes rdar://24306342

Reviewers: JDevlieghere, aprantl, shafik, #lldb

Reviewed By: JDevlieghere, #lldb

Subscribers: usaxena95, davide, jingham, aprantl, arphaman, kadircet, lldb-commits

Tags: #lldb

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

llvm-svn: 372203

function_ref causes calls to the function to be ambiguous, breaking
compilation.

Reverting for now.

llvm-svn: 372202

Summary:
The latter is slightly more efficient and communicates the intent of the
API: writeFileAtomically does not own or copy the callback, it merely
calls it at some point.

Reviewers: jkorous

Reviewed By: jkorous

Subscribers: hiraditya, dexonsmith, jfb, llvm-commits, cfe-commits

Tags: #llvm

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

llvm-svn: 372201

This generates worse code, but matches what is done for avx2 and
prevents crashes when more arguments are passed than we have
registers for.

llvm-svn: 372200

llvm-svn: 372199

Currently, not all user specified relocations
(with clang intrinsic __builtin_preserve_access_index())
will turn into relocations.

In the current implementation, a __builtin_preserve_access_index()
chain is turned into relocation only if the result of the clang
intrinsic is used in a function call or a nonzero offset computation
of getelementptr. For all other cases, the relocatiion request
is ignored and the __builtin_preserve_access_index() is turned
into regular getelementptr instructions.
The main reason is to mimic bpf_probe_read() requirement.

But there are other use cases where relocatable offset is
generated but not used for bpf_probe_read(). This patch
relaxed previous constraints when to generate relocations.
Now, all user __builtin_preserve_access_index() will have
relocations generated.

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

llvm-svn: 372198

As seen in the most recent updates to PR10498

llvm-svn: 372197

I don't know what the intent of parts of this test were.  We set a
bunch of breakpoints and ran from one to the other, doing "self.runCmd("thread backtrace")"
then continuing to the next one.  We didn't actually verify the contents of the backtrace,
nor that we hit the breakpoints we set in any particular order.  The only actual test was
to run sel_getName at two of these stops.

So I reduced the test to just stopping at the places where we were actually going to run
an expression, and tested the expression.

llvm-svn: 372196

The filename in the RemarkStreamer should be optional to allow clients
to stream remarks to memory or to existing streams.

This introduces a new overload of `setupOptimizationRemarks`, and avoids
enforcing the presence of a filename at different places.

llvm-svn: 372195

Summary: This way it can be overwritten when cross compiling.

Subscribers: mgorny, lldb-commits

Tags: #lldb

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

llvm-svn: 372194

This test is about disassembling symbols in a framework without debug information.
So we don't need to run it once per debug info flavor.

llvm-svn: 372193

Jim pointed out that the LLDB global variables should only be available
in interactive mode. When used from a command for example, their values
might be stale or not at all what the user expects. Therefore we want to
explicitly make these variables unavailable.

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

llvm-svn: 372192

Starting from r324788 timer groups aren't cleared automatically when
printed out. As a result some timer groups were printed one more time.
For example, "Pass execution timing report" was printed again in
`ManagedStatic<PassTimingInfo>` destructor, "DWARF Emission" in
`ManagedStatic<Name2PairMap> NamedGroupedTimers` destructor.

Fix by clearing timer groups manually.

Reviewers: thegameg, george.karpenkov

Reviewed By: thegameg

Subscribers: aprantl, jkorous, dexonsmith, ributzka, aras-p, cfe-commits

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

llvm-svn: 372191

This method is never called.

llvm-svn: 372190

Summary:
The PGO counter reading will add cold and inlinehint (hot) attributes
to functions that are very cold or hot. This was using hardcoded
thresholds, instead of the profile summary cutoffs which are used in
other hot/cold detection and are more dynamic and adaptable. Switch
to using the summary-based cold/hot detection.

The hardcoded limits were causing some code that had a medium level of
hotness (per the summary) to be incorrectly marked with a cold
attribute, blocking inlining.

Reviewers: davidxl

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 372189

Since the removal of extensions nodes from schedule trees in r362257 it
is possible to emit parallel code for SCoPs containing
matrix-multiplications. However, the code looking for references used in
outlined statement was not prepared to handle CopyStmts introduced by
the matrix-matrix multiplication detection.

In this case, CopyStmts do not introduce references in addition to the
ones captured by MemoryAccesses, i.e. we change the assertion to accept
CopyStmts and add a regression test for this case.

This fixes llvm.org/PR43164

llvm-svn: 372188

Matching fix for https://reviews.llvm.org/D67375 (r372186).

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

llvm-svn: 372187

r361845 changed the way we handle "D16" vs. "D32" targets; there used to
be a negative "d16" which removed instructions from the instruction set,
and now there's a "d32" feature which adds instructions to the
instruction set.  This is good, but there was an oversight in the
implementation: the behavior of VFPv2 was changed.  In particular, the
"vfp2" feature was changed to imply "d32". This is wrong: VFPv2 only
supports 16 D registers.

In practice, this means if you specify -mfpu=vfpv2, the compiler will
generate illegal instructions.

This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2" and
"vfp2sp" so they don't imply "d32".

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

llvm-svn: 372186

This reverts commit a08d5a4b.

llvm-svn: 372185

Also, add a diagnostic group, -Wobjc-signed-char-bool, to control all these
related diagnostics.

rdar://51954400

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

llvm-svn: 372183

For COFF, a comdat group is really a symbol marked
IMAGE_COMDAT_SELECT_ANY and zero or more other symbols marked
IMAGE_COMDAT_SELECT_ASSOCIATIVE. Typically the associative symbols in
the group are not external and are not referenced by other TUs, they are
things like debug info, C++ dynamic initializers, or other section
registration schemes. The Visual C++ linker reports a duplicate symbol
error for symbols marked IMAGE_COMDAT_SELECT_ASSOCIATIVE even if they
would be discarded after handling the leader symbol.

Fixes coverage-inline.cpp in check-profile after r372020.

llvm-svn: 372182

Fix the warning.
Bugpoint.rst:124:Mismatch: both interpreted text role prefix and
reference suffix.

Note that the line no here is wrong and misleading,
the problem is in line 128, not 124.

llvm-svn: 372181

Behavior'

Create a new section for documenting the floating point options. Move
all the floating point options into this section, and add new entries
for the floating point options that exist but weren't previously
  described in the UsersManual.

Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D67517

llvm-svn: 372180

MSVC doesn't correctly capture constexpr in lambdas, and other builds warn if you do, others will error out if you do. Avoid lambdas.

llvm-svn: 372179

Exception specifiers are now part of the function type in C++17.
Normally, it is illegal to redeclare the same function or specialize a
template with a different exception specifier, but under
-fms-compatibility, we accept it with a warning. Without this change,
the function types would not match due to the exception specifier, and
clang would claim that the types were "incompatible". Now we emit the
warning and merge the redeclaration as we would in C++14 and earlier.

Fixes PR42842, which is about compiling _com_ptr_t in C++17.

Based on a patch by Alex Fusco <alexfusco@google.com>!

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

llvm-svn: 372178

This adds support for `-tailcallopt` tail calls to CallLowering. This
piggy-backs off the changes from D67577, since doing it without a bit of
refactoring gets extremely ugly.

Support is basically ported from AArch64ISelLowering. The main difference here
is that tail calls in `-tailcallopt` change the ABI, so there's some extra
bookkeeping for the stack.

Show that we are correctly lowering these by updating tail-call.ll.

Also show that we don't do anything strange in general by updating
fastcc-reserved.ll, which passes `-tailcallopt`, but doesn't emit any tail
calls.

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

llvm-svn: 372177

When running in the default mode we don't print anything other than actual output to stdout to make automated processing easier.

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

llvm-svn: 372174

llvm-svn: 372173

llvm-svn: 372172

llvm-svn: 372171

While we already fold that pattern if the sum of shift amounts is not
smaller than bitwidth, there's painfully obvious generalization:
  https://rise4fun.com/Alive/F5R
I.e. the "sub of shift amounts" tells us how many bits will be left
in the output. If it's less than bitwidth, we simply need to
apply a mask, which is constant.

llvm-svn: 372170

This reverts commit c98ec609, which broke the sphinx-docs build.

llvm-svn: 372168

llvm-svn: 372166

llvm-svn: 372165