Fix #61691

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

Apparently it was used to work around some issue that has been fixed.
Removing it helps with high scratch usage observed in some cases due to failed alloca promotion.

Reviewed By: rampitec

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

According to
https://llvm.org/docs/HowToUpdateDebugInfo.html#when-to-preserve-an-instruction-location,
when moving (and in our case cloning) within the same BB, the debug
location is preserved. But when moving / cloning to a different BB, we
preserve the debug location only if the destination BB contains the same
location. Currently we preserve the debug loc unconditionally in all
cases. This CL correctly handles the debug locs in DebugValueManager.

Reviewed By: dschuff

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

The current lowering fails to retrieve the shape of polymorphic array
arguments in elemental procedure reference.
Add a TODO because this is supported in the new HLFIR lowering, and
because the current lowering anyway attempts to re-evaluate the
argument to get its shape, which is not correct if the evaluation
has side effects.

Add a test to ensure this is supported with HLFIR.

Reviewed By: PeteSteinfeld

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

The requirement for PIE of hwasan was introduced in https://reviews.llvm.org/D44745,  this patch removes requirement for PIE.

Reviewed By: vitalybuka, MaskRay

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

This reverts commit 5f0bccc3.

An issue has been reported here: https://github.com/ClangBuiltLinux/linux/issues/1833

Toggle true/false values of the JumpToFallThrough
parameter to simplify code and make it consistent
with the documentation for the `getFallThrough(..)`
method.

Reviewed By: bcahoon

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

Patch by Aleksandr Popov!

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

fixes https://github.com/llvm/llvm-project/issues/61309

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

FullLoopUnroll was performing runtime unrolling in certain cases when
'#pragma unroll' was specified. Patch to fix this by introducing new parameter
to tryToUnrollLoop() to differentiate between LoopUnrollPass and
FullLoopUnrollPass. Based on the discussion here
(https://discourse.llvm.org/t/loop-unroller-fails-to-unroll-loop/69834)

Reviewed By: nikic

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

This comment was probably mangled when the generic ELFLinkGraphBuilder was
written from the original x86-64 specific version. Regardless of its origins,
it doesn't make any sense now.

Instead of storing a string containing the instruction name, store a
reference to the instruction. We can use that reference to print the
instruction name when we emit the table.

The only slightly annoying part is that we have to find the
CodeGenInstruction for IMPLICIT_DEF. GlobalISel is doing
a similar thing.

The pre-link pipeline already ran the pass and it only needs to be run once.

Reviewed By: nikic

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

Reviewed By: aartbik

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

Lowering the call op with use-bare-ptr-memref-call crashes due to the unsupported unranked memref type. We can prevent the crash by checking the type of operand in the pass instead of the assertion in the type converter.

Issue: https://github.com/llvm/llvm-project/issues/61872

Reviewed By: ftynse

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

Have debugserver parse the watchpoint flags out of the exception
syndrome register when we get a watchpoint mach exception.  Relay
those fields up to lldb in the stop reply packet, if the watchpoint
number was reported by the hardware, use the address from that as
the watchpoint address.

Change how watchpoints are reported to lldb from using the mach
exception data, to using the `reason:watchpoint` and `description:asciihex`
method that lldb-server uses, which can relay the actual trap address
as well as the address of a watched memory region responsible for
the trap, so lldb can step past it.

Have debugserver look for the nearest watchpoint that it has set
when it gets a watchpoint trap, so accesses that are reported as
starting before the watched region are associated with the correct
watchpoint to lldb.  Add a test case for this specific issue.

Differential Revision: https://reviews.llvm.org/D147820
rdar://83996471

Watchpoints from lldb-server are sent in the stop info packet
as a `reason:watchpoint` and `description:asciihex` keys; the
latter's asciihex has one to three integer values.  This patch
documents the purpose of those three different numbers, and
clarifies the behavior on MIPS with the third number which is
outside the range of any watched memory range means to silently
skip the watchpoint.

lldb was previously using this silently skip watchpoint behavior
for AArch64 as well, but in the case of AArch64 we see a watchpoint
address outside of a watched memory range when the write BEGINS
before the watched memory range, but extends in to it.  We don't
want to silently skip these.

Differential Revision: https://reviews.llvm.org/D147816
rdar://83996471

No test diff; noticed via inspection.

`lowerShuffleAsUNPCKAndPermute` requires the shuffle mask element to be
in the same lane in both the input and output vectors. This prevents it from
matching certain patterns for example in [GHI
61964](https://github.com/llvm/llvm-project/issues/61964). Removing the lane
requirement fixes the issue.

The change I'm targeting is in the test llvm/test/CodeGen/X86/pr61964.ll. The
codegen has improved notably with this patch. Otherwise, looks like some
broadcast instructions are replaced with unpck and perm. To check if there's
any other performance change, I ran llvm-test-suite benchmarks from the
SingleSource, MultiSource, and MicroBenchmarks directories:
```
Tests: 2665
Short Running: 2009 (filtered out)
Same hash: 140 (filtered out)
In Blacklist: 513 (filtered out)
Remaining: 3
Metric: exec_time

Program                                                                exec_time
                                                                       lhs       rhs    diff
 test-suite :: MultiSource/Benchmarks/ASCI_Purple/SMG2000/smg2000.test   1.64      1.64  0.1%
      test-suite :: SingleSource/Benchmarks/Adobe-C++/loop_unroll.test   1.06      1.06  0.0%
          test-suite :: MultiSource/Applications/JM/lencod/lencod.test   5.25      5.25  0.0%
                                                    Geomean difference    nan       nan  0.0%
      exec_time
l/r         lhs       rhs      diff
count  3.000000  3.000000  3.000000
mean   2.648300  2.649100  0.000462
std    2.269035  2.268849  0.000415
min    1.055500  1.055900  0.000095
25%    1.349300  1.350250  0.000237
50%    1.643100  1.644600  0.000379
75%    3.444700  3.445700  0.000646
max    5.246300  5.246800  0.000913
```
The patch only hits three cases and the result is neutral. (The 513 blacklisted
benchmarks are the ones under MicroBenchmarks, which `--filter-hash` does
not work and I manually verified their code did not change).

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

Test was incorrectly named/commented after the sched_{set|get}affinity
functions.

Reviewed By: michaelrj

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

`getrandom` should return the number of bytes successfully set on
success, not `0`.

Reviewed By: sivachandra, michaelrj

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

Implements: https://linux.die.net/man/2/sched_yield

Possibly we don't need the return value check / errno as according to
both the manpage (and current linux source) `sched_yield` cannot fail.

Reviewed By: sivachandra, michaelrj

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

This patch enables sparc and mips in compiler-rt CRT, meaning that now every platform supported by compiler-rt builtins (that runs on Linux, i.e. not WebAssembly) will be suported by compiler-rt CRT

Reviewed By: phosek, MaskRay

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

An assertion in Qualifiers::addObjCLifetime fails when the ObjC lifetime
bits are already set.

Instead of calling operator+=, call addConsistentQualifiers, which
allows the lifetime bits to be set again as long the new value doesn't
conflict with the old value.

This fixes https://github.com/llvm/llvm-project/issues/61419.

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

These reduce the typing and clutter from:
Register Dst = MI.getOperand(0).getReg();
Register Src1 = MI.getOperand(1).getReg();
Register Src2 = MI.getOperand(2).getReg();
Register Src3 = MI.getOperand(3).getReg();
LLT DstTy = MRI.getType(Dst);
... etc etc

To just:
auto [Dst, Src1, Src2, Src3] = MI.getFirst4Regs();
auto [DstTy, Src1Ty, Src2Ty, Src3Ty] = MI.getFirst4LLTs();

Or even more concise:
auto [Dst, DstTy, Src1, Src1Ty, Src2, Src2Ty, Src3, Src3Ty] =
     MI.getFirst4RegLLTs();

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

[GlobalISel] Move the truncstore_merge combine to the LoadStoreOpt pass and add support for an extra case.

If we have set of mergeable stores of shifts, but the original source value being shifted
is wider than the merged size, we should still be able to merge if we truncate first. To do this
however we need to search for stores speculatively up the block, without knowing exactly how
many stores we should see before we stop. The old algorithm has to match an exact number of
stores to fit the wide type, or it dies. The new one will try to set the wide type to however
many stores we found in the upwards block traversal and use later checks to verify if they're
a valid mergeable set.

The reason I need to move this to LoadStoreOpt is because the combiner works going top down
inside a block, which means that we end up doing partial merges because we haven't seen all
the possible stores before we mutate the MIR. In LoadStoreOpt we can go bottom up.

As a side effect of this change, we also end up doing better on an existing test case (missing_store)
since we manage to do a partial merge there.

To calculate the trip count we need to add 1 to the backedge
taken count. If we need to widen the backedge count, it's better
to do the add before the widening if we can guarantee it won't
overflow.

The code here is based on similar code I found in
LoopIdiomRecognize.

This is the vectorizer version of this InstCombine patch D142783.
Looking at the IR diffs, this does look like it gets more cases
than the InstCombine patch.

Reviewed By: reames

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

Use the oilist syntax in assembly format where appropriate.
This makes the dialect format more flexible as an order
is not imposed for the clauses.

Reviewed By: PeteSteinfeld, razvanlupusoru

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

This patch should fix an assertion that causes some test failures:
https://ci.swift.org/view/LLDB/job/llvm-org-lldb-release-debuginfo/3587/console

This was caused by the changes introduces in `88f40919` where we
replaced `DidLaunch` by `DidResume` in the `ScriptedProcess` class.

However, by the time we resume the process, the pid should be already
set. To address this, this patch brings back `DidLaunch` which will
initialize the ScriptedProcess pid with a placeholder value. That value
will be updated in `DidResume` to the final pid.

Note, this 2 stage PID initialization is necessary sometimes, when the
scripted process gets stopped at entry (launch) and gets assigned an
object that contains the PID value. In this case, we need to update the
PID when we resume the process after we've stopped at entry.

This also replaces the default scripted process id to an arbitrary
number (42) since the current value (0) is considered invalid.

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

FileCheck is not very useful here.

String to float has a condition to prevent overflowing the exponent with
the E notation. To do this it checks if adding that exponent to the
exponent found by parsing the number is greater than the maximum
exponent for the given size of float. The if statements had a gap on
exactly the maximum exponent value that caused it to be treated as the
minimum exponent value. This patch fixes those conditions.

Reviewed By: lntue

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

This reverts commit 3820e9a2.

See https://reviews.llvm.org/D146987 for issues.

For a pointer type expression `e` of the form `++DRE`, if `e` is under
an Unspecified Pointer Context (UPC) and `DRE` is suppose to be
transformed to have std:span type, we generate fix-its that transform `e` to
`(DRE = DRE.subspan(1)).data()`.

For reference, `e` is in an UPC if `e` is
- an argument of a function call (except the callee has [[unsafe_buffer_usage]] attribute), or
- the operand of a cast-to-(Integer or Boolean) operation; or
- the operand of a pointer subtraction operation; or
- the operand of a pointer comparison operation;

We may extend the definition of UPC by adding more cases later.

Reviewed by: NoQ (Artem Dergachev)

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