Summary:
RISC-V uses a post-select peephole pass to optimise
`(load/store (ADDI $reg, %lo(addr)), 0)` into `(load/store $reg, %lo(addr))`.
This peephole wasn't firing for accesses to constant pools, which is how we
materialise most floating point constants.

This adds support for the constantpool case, which improves code generation for
lots of small FP loading examples. I have not added any tests because this
structure is well-covered by the `fp-imm.ll` testcases, as well as almost
all other uses of floating point constants in the RISC-V backend tests.

Reviewed By: luismarques, asb

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

This patch addresses two issues related to adding inline functions to the import list while recursively going through the profiling data.
1. For callsite samples, only add an inlined function to the import list if it's from outside of the module (i.e. only has a declaration inside the module).
2. For body samples, add each target function to the import list if it's from outside of the module (i.e. only has a declaration inside the module). Previously we were using getSubProgram() to check whether it has dbg info, which is inaccurate. This fix properly add imports and could improve the quality of the pass.

Added a few changes to the test to catch these cases.

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

Summary:
TestNSDictionarySynthetic sets up an NSURL which does not initialize its
_baseURL member. When the test runs and we print out the NSURL, we print
out some garbage memory pointed-to by the _baseURL member, like:

```
_baseURL = 0x0800010020004029 @"d��qX"
```

and this can cause a python unicode decoding error like:

```
UnicodeDecodeError: 'utf8' codec can't decode byte 0xa0 in position
10309: invalid start byte
```

There's a discrepancy here because lldb's StringPrinter facility tries
to only print out "printable" sequences (see: isprint32()), whereas python
rejects the StringPrinter output as invalid utf8. For the specific error
seen above, lldb's `isprint32(0xa0) = true`, even though 0xa0 is not
really "printable" in the usual sense.

The problem is that lldb and python disagree on what exactly is
"printable". Both have dismayingly hand-rolled utf8 validation code
(c.f. _Py_DecodeUTF8Ex), and I can't really tell which one is more
correct.

I tried replacing lldb's isprint32() with a call to libc's iswprint():
this satisfied python, but broke emoji printing :|.

Now, I believe that lldb (and python too) ought to just call into some
battle-tested utf library, and that we shouldn't aim for compatibility
with python's strict unicode decoding mode until then.

FWIW I ran this test under an ASanified lldb hundreds of times but
didn't turn up any other issues.

rdar://62941711

Reviewers: JDevlieghere, jingham, shafik

Subscribers: lldb-commits

Tags: #lldb

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

Create a sanitizer_ptrauth.h header that #includes <ptrauth> when
available and defines just the required macros as "no ops" otherwise.
This should avoid the need for excessive #ifdef'ing.

Follow-up to and discussed in: https://reviews.llvm.org/D79132

Reviewed By: delcypher

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

This is an implementation of Speculative Execution Side Effect
Suppression which is intended as a last resort mitigation against Load
Value Injection, LVI, a newly disclosed speculative execution side
channel vulnerability.

One pager:
https://software.intel.com/security-software-guidance/software-guidance/load-value-injection

Deep dive:
https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection

The mitigation consists of a compiler pass that inserts an LFENCE before
each memory read instruction, memory write instruction, and the first
branch instruction in a group of terminators at the end of a basic
block. The goal is to prevent speculative execution, potentially based
on misspeculated conditions and/or containing secret data, from leaking
that data via side channels embedded in such instructions.

This is something of a last-resort mitigation: it is expected to have
extreme performance implications and it may not be a complete mitigation
due to trying to enumerate side channels.

In addition to the full version of the mitigation, this patch
implements three flags to turn off part of the mitigation. These flags
are disabled by default. The flags are not intended to result in a
secure variant of the mitigation. The flags are intended to be used by
users who would like to experiment with improving the performance of
the mitigation. I ran benchmarks with each of these flags enabled in
order to find if there was any room for further optimization of LFENCE
placement with respect to LVI.

Performance Testing Results

When applying this mitigation to BoringSSL, we see the following
results. These are a summary/aggregation of the performance changes when
this mitigation is applied versus when no mitigation is applied.

Fully Mitigated vs Baseline
Geometric mean
0.071 (Note: This can be read as the ops/s of the mitigated
program was 7.1% of the ops/s of the unmitigated program.)
Minimum
0.041
Quartile 1
0.060
Median
0.063
Quartile 3
0.077
Maximum
0.230

Reviewed By: george.burgess.iv

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

This [discussion](https://llvm.discourse.group/t/viewop-isnt-expressive-enough/991/2) raised some concerns with ViewOp.

In particular, the handling of offsets is incorrect and does not match the op description.
Note that with an elemental type change, offsets cannot be part of the type in general because sizeof(srcType) != sizeof(dstType).

Howerver, offset is a poorly chosen term for this purpose and is renamed to byte_shift.

Additionally, for all intended purposes, trying to support non-identity layouts for this op does not bring expressive power but rather increases code complexity.

This revision simplifies the existing semantics and implementation.
This simplification effort is voluntarily restrictive and acts as a stepping stone towards supporting richer semantics: treat the non-common cases as YAGNI for now and reevaluate based on concrete use cases once a round of simplification occurred.

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

Summary:
These tools are no longer useful since we've migrated off of SVN, so
this patch deletes them.

RFC Link: http://lists.llvm.org/pipermail/llvm-dev/2020-May/141386.html

Unless there is opposition in the RFC thread, I'll submit the patch on
May 10, 2020.

I searched through the repo to confirm there were no mentions of the scripts
in other scripts or documentation.

Reviewed By: echristo, tstellar, MaskRay

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

Summary:
The Hygon Dhyana processor supports hardware CRC32.

Related link:
https://reviews.llvm.org/D78874

Result of "make check":
Testing Time: 1364.04s
  Unsupported Tests:   317
  Expected Passes  : 36802
  Expected Failures:   161
[100%] Built target check-llvm
[100%] Built target check

Reviewers: cryptoad

Reviewed By: cryptoad

Subscribers: craig.topper, cryptoad, cfe-commits, #sanitizers, llvm-commits

Tags: #clang, #sanitizers, #llvm

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

Summary: Factoring out in preparation to https://reviews.llvm.org/D79042

Reviewers: dblaikie, davidxl

Subscribers: mgorny, eraman, hiraditya, llvm-commits

Tags: #llvm

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

The bot fails with a message which seems to indicate a problem in option
parsing. Avoid grouping the options to see if that helps.

Reviewers: jdoerfert, sstefan1, uenoku

Reviewed By: uenoku

Subscribers: hiraditya, uenoku, llvm-commits

Tags: #llvm

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

Summary:
This patch will set the variable PredictableSelectIsExpensive to do the
select to if based on BranchProbability in CodeGenPrepare.

When the BranchProbability more than MinPercentageForPredictableBranch,
PPC will convert SELECT to branch.

Reviewed By: nemanjai

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

Fixing the return type of atomic_is_lock_free as per
https://en.cppreference.com/w/c/atomic/atomic_is_lock_free

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

Summary: This revision introduces LinalgPromotionOptions to more easily control the application of promotion patterns. It also simplifies the different entry points into Promotion in preparation for some behavior change in subsequent revisions.

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

Revert "[DAGCombine] Remove the getNegatibleCost to avoid the out of sync with getNegatedExpression"

This reverts commit 3c44c441.

Causes infloops on some inputs, see https://reviews.llvm.org/D77319 for repro

Summary:
The test machinery translates each continuous block of "//%" comments
into a single breakpoint. If there's no code between the blocks the
breakpoints will end up at the same location in the program. When the
process stops at a breakpoint lldb correctly reports all breakpoint IDs,
but the test machinery only looks at the first one. This results in a
very dangerous situation as it means some checks can be silently
stopped.

This patch fixes that by making the test machinery iterate through all
breakpoints at a given location and execute all commands.

Reviewers: vsk, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

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

Summary:
This function rewrites the test to be (hopefully) less susceptible to
codegen changes and re-enables it.

The most interesting changes are:
- use an __attribute__((optnone)) function instead of a volatile asm to
  "use" a value. This isn't strictly necessary, but it makes the
  function simpler while achieving the same effect.
- use a call to a function with the exact same signature instead of a
  volatile asm to "destroy" arguments. This makes the independent of the
  ABI, and (together with avoiding the usage of the arguments after the
  call) ensures that the compiler has no reason to move the argument
  from its initial register (previously we needed to guess where will
  the compiler store the arguments).

Reviewers: vsk, djtodoro, dblaikie

Subscribers: lldb-commits

Tags: #lldb

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

Because those can get really weird sometimes.

Summary: This adds xdlops (mfma) to the rocdl dialect and also tests the translation to llvm ir.

Reviewers: ftynse

Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits

Tags: #llvm #mlir

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

Summary:
We got a few crash reports where LLDB crashes while derefencing the `frames_value` shared_ptr in the AppleObjCRuntime::GetBacktraceThreadFromException. `GetChildMemberWithName` returns a nullptr when an error occurs, so this seems to be just a missing nullptr check.

This patch adds that nullptr check and the other ones in the similar code directly below.

Fixes rdar://62174039

Reviewers: jingham, kubamracek

Reviewed By: jingham

Subscribers: abidh, JDevlieghere

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

Summary: Apply the common completion created in [[ https://reviews.llvm.org/D75418 | Revision D75418 ]] to the commands  `breakpoint write` and `breakpoint name add/delete`.

Reviewers: teemperor, JDevlieghere

Reviewed By: teemperor

Tags: #lldb

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

Add documentation to `isToLevelValue` explaining its behavior for
detached regions, and fix the overloaded version that accepts `Region`.

Both the .ARM.exidx and .eh_frame sections have a custom SyntheticSection
that acts as a container for the InputSections. The InputSections are added
to the SyntheticSection prior to /DISCARD/ which limits the affect a
/DISCARD/ can have to the whole SyntheticSection. In the majority of cases
this is sufficient as it is not common to discard subsets of the
InputSections. The Linux kernel has one of these scripts which has something
like:
/DISCARD/ : { *(.ARM.exidx.exit.text) *(.ARM.extab.exit.text) ... }
The .ARM.exidx.exit.text are not discarded because the InputSection has been
transferred to the Synthetic Section. The *(.ARM.extab.exit.text) sections
have not so they are discarded. When we come to write out the .ARM.exidx
sections the dangling references from .ARM.exidx.exit.text to
.ARM.extab.exit.text currently cause relocation out of range errors, but
could as easily cause a fatal error message if we check for dangling
references at reloc...

Summary:
1. A new common completion `CommandCompletions::Breakpoints` to provide a list of the breakpoints of the current context;
2. Apply the completion above to the commands breakpoint enable/disable/delete/modify;
3. Unit test.

Reviewers: teemperor, JDevlieghere

Reviewed By: teemperor

Tags: #lldb

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

This dialect contains various structured control flow operaitons, not only
loops, reflect this in the name. Drop the Ops suffix for consistency with other
dialects.

Note that this only moves the files and changes the C++ namespace from 'loop'
to 'scf'. The visible IR prefix remains the same and will be updated
separately. The conversions will also be updated separately.

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

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, llvm-commits

Tags: #llvm

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

Summary:
this patch fixe crash/asserts found in the test-suite.
the AssumeptionCache cannot be assumed to have all assumes contrary to what i tought.
prevent generation of information for terminators, because this can create broken IR in transfromation where we insert the new terminator before removing the old one.

Reviewers: jdoerfert

Reviewed By: jdoerfert

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

don't span their entire scope.

The previous commit (6d1c40c1) is an older version of the test.

Reviewed By: aprantl, vsk

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

don't span their entire scope.

The previous commit (6d1c40c1) is an older version of the test.

Reviewed By: aprantl, vsk

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

don't span their entire scope.

Reviewed By: aprantl, vsk

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

These builtins are expanded in CGBuiltin to use intrinsics
for (signed/unsigned) shift left long top/bottom.

Reviewers: efriedma, SjoerdMeijer

Reviewed By: efriedma

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

Summary: We were serializing it no matter what, which was against the spec

Reviewers: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

Summary: Depends On D79374

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

Summary: Depends On D79373

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

Summary:
Cast from a value interpreted as floating-point to the corresponding signed
integer value. Similar to an element-wise `static_cast` in C++, performs an
element-wise conversion operation.

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

It is bad practice to capture by default (via [&] in this case) when
using lambdas, so we should avoid that as much as possible.

This patch fixes that in the getForwardingRegsDefinedByMI
from DwarfDebug module.

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

The test was missed in 8222107a.