Steve Klabnik recently left the Rust project. Josh Stone (the other member of
the Rust Security Response WG) replaces him as one of the vendor contacts for
Rust.

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

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

This brings clang/llvm into line with GCC. The Pass is still enabled for
the affected cores, but is now opt-in when using `-march=`.

I also took the opportunity to add release notes for this change.

Reviewed By: john.brawn

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

Lowering through libm gives us a baseline version, even though it's not
going to be particularly fast. This is similar to what we do for some
math dialect ops.

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

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

Removed code that is no longer used after https://reviews.llvm.org/D124485.

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

Non-address bits are not part of the virtual address in a pointer.
So they must be removed before passing to interfaces like ptrace.

Some of them we get way with not removing, like AArch64's top byte.
However this is only because of a hardware feature that ignores them.

This change updates all the Process/Target Read/Write memory methods
to remove non-address bits before using addresses.

Doing it in this way keeps lldb-server simple and also fixes the
memory caching when differently tagged pointers for the same location
are read.

Removing the bits is done at the ReadMemory level not DoReadMemory
because particualrly for process, many subclasses override DoReadMemory.

Tests have been added for read/write at the command and API level,
for process and target. This includes variants like
Read<sometype>FromMemory. Commands are tested to make sure we remove
at the command and API level.

"memory find" is not included because:
* There is no API for it.
* It already has its own address handling tests.

Software breakpoints do use these methods but they are not tested
here because there are bigger issues to fix with those. This will
happen in another change.

Reviewed By: omjavaid

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

This reverts commit 8e648f19
due to test failures on Windows:
https://lab.llvm.org/buildbot/#/builders/83/builds/19094

Typos meant that the update script never removed them

[DebugInfo][X86] debug-info-template-parameter.ll - fix broken DW_AT_default_value checks identified in D125604

GlobalISel tests are barely supported on X86, so just regenerate for now to avoid a blocker

CodeGen will only produce fixed formwat prologues, but hand-written assembly
can have .cfi directives in any combination they want. This should cause a
fallback to DWARF rather than an assertion failure (or an incorrect compact
unwind if assertions are disabled).

This adds an option to the memory region command
to print all regions at once. Like you can do by
starting at address 0 and repeating the command
manually.

memory region [-a] [<address-expression>]

(lldb) memory region --all
[0x0000000000000000-0x0000000000400000) ---
[0x0000000000400000-0x0000000000401000) r-x <...>/a.out PT_LOAD[0]
<...>
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0001000000000000-0xffffffffffffffff) ---

The output matches exactly what you'd get from
repeating the command. Including that it shows
unmapped areas between the mapped regions.

(this is why Process GetMemoryRegions is not
used, that skips unmapped areas)

Help text has been updated to show that you can have
an address or --all but not both.

Reviewed By: JDevlieghere

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

Completes
https://reviews.llvm.org/D125117

Reviewed By: dp, arsenm

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

This code is valid for any icmp, so we can safely look through a
freeze when trying to find one.

A caveat here is that replaceFoldableUses() may not end up replacing
any uses in this case. It might make sense to use the freeze as the
context instruction (rather than the terminator) if there is a
freeze, to ensure that it always gets folded. This would require
some changes to how replaceFoldedUses() works though, as it
currently assumes that the value is valid at the end of the block.

Fold immediates regardless of how many uses they have. This is expected
to increase overall code size, but decrease register usage.

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

These are for the getPredicateAt() codepath.

With change reporting in transformation passes in mind.

The modified function was incorrectly (not unnecessarily) ignoring grandchild
loops, and this change fixes the bug. In particular, this fixes the handling of
the loop { inner, body }. The TODO in the same function is talking about the b1
self loop, which may be "unnecessarily" lost, but that is a different issue.

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

It's sufficient to just fold the icmp to true/false here, and then
let constant terminator folding take care of the rest.

It should be noted that while replaceFoldableUses() may not replace
all uses of the icmp, at least the use in the terminator we're
working on is always replaceable, so terminator constant folding
should be reliably enabled as a subsequent step.

Previously SIFoldOperands::foldInstOperand would only fold a
non-inlinable immediate into a single user, so as not to increase code
size by adding the same 32-bit literal operand to many instructions.

This patch removes that restriction, so that a non-inlinable immediate
will be folded into any number of users. The rationale is:
- It reduces the number of registers used for holding constant values,
  which might increase occupancy. (On the other hand, many of these
  registers are SGPRs which no longer affect occupancy on GFX10+.)
- It reduces ALU stalls between the instruction that loads a constant
  into a register, and the instruction that uses it.
- The above benefits are expected to outweigh any increase in code size.

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

This avoids use-after-free when trying to access the regions after visiting
the operation.

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

GetDirtyPageList was being assigned to const & in most places anyway.
If you wanted to change the list you'd make a new one and call
SetDirtyPageList.

GetPageSize is just an int so no issues being const.

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

There are multiple places that want to look through freeze, so
store condition without freeze in a separate variable.

This new CTU implementation is the natural extension of the normal single TU
analysis. The approach consists of two analysis phases. During the first phase,
we do a normal single TU analysis. During this phase, if we find a foreign
function (that could be inlined from another TU) then we don’t inline that
immediately, we rather mark that to be analysed later.
When the first phase is finished then we start the second phase, the CTU phase.
In this phase, we continue the analysis from that point (exploded node)
which had been enqueued during the first phase. We gradually extend the
exploded graph of the single TU analysis with the new node that was
created by the inlining of the foreign function.

We count the number of analysis steps of the first phase and we limit the
second (ctu) phase with this number.

This new implementation makes it convenient for the users to run the
single-TU and the CTU analysis in one go, they don't need to run the two
analysis separately. Thus, we name this new implementation as "onego" CTU.

Discussion:
https://discourse.llvm.org/t/rfc-much-faster-cross-translation-unit-ctu-analysis-implementation/61728

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

Summary:
Add a new function with which we can query if a Decl had been newly
created during the import process. This feature is a must if we want to
have a different static analysis strategy for such newly created
declarations.

This is a dependent patch that is needed for the new CTU implementation
discribed at
https://discourse.llvm.org/t/rfc-much-faster-cross-translation-unit-ctu-analysis-implementation/61728

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

x86-target-features.c can spuriously fail when checking for absence of
the string "lvi" in the compiler output due to the temporary path used
for the output file. For example:
"-o" "/tmp/lit-tmp-981j7lvi/x86-target-features-670b86.o"
will make the test fail. This commit checks specifically for lvi as a
target feature, in a similar way to the positive CHECK directive just
above.

Test Plan: fails when using -mlvi-hardening and pass otherwise

Reviewed By: pengfei

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

Add support for reading response files in the flang driver. Response
files contain command line arguments and are used whenever a command
becomes longer than the shell/environment limit. Response files are
recognized via the special "@path/to/response/file.rsp" syntax, which
distinguishes them from other file inputs.

This patch hardcodes GNU tokenization, since we don't have a CL mode for
the driver. In the future we might want to add a --rsp-quoting command
line option, like clang has, to accommodate Windows platforms.

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

The patch does not pass math flags to float VPCmpIntrinsics because LLParser
could not identify float VPCmpIntrinsics as FPMathOperators.

Reviewed By: craig.topper

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

This is compiled as C code, so it's a good idea to be explicit about the
prototype. Clang complains about this when -Wstrict-prototypes is used.

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

This fixes bug 55463, similar to D78668. This is a temporary fix since
we will switch to post-isel CTR loop determination in the future.

Reviewed By: dim, shchenz

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

The previous fix from af371f9f only applied when using a bottom-up
traversal. The change here applies the constant preprocessing logic to the
top-down case as well. This resolves the issue with the canonicalizer pass still
reordering constants, since it uses a top-down traversal by default.

Fixes #51892

Reviewed By: rriddle

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

%x umin_seq %y is currently expanded to %x == 0 ? 0 : umin(%x, %y).
This patch changes the expansion to umin(%x, freeze %y) instead
(https://alive2.llvm.org/ce/z/wujUhp).

The motivation for this change are the test cases affected by
D124910, where the freeze expansion ultimately produces better
optimization results. This is largely because
`(%x umin_seq %y) == %x` is a common expansion pattern, which
reliably optimizes in freeze representation, but only sometimes
with the zero comparison (in particular, if %x == 0 can fold to
something else, we generally won't be able to cover reasonable
code from this.)

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