The `Twine::str()` function currently always allocates heap memory via `std::string`. However, some instances of `Twine` don't need an intermediate buffer at all, and the rest can attempt to print into a stack buffer first.

This is intentionally not making use of `Twine::isSingleStringLiteral()` from D157010 to skip saving the string in the bump-pointer allocator, since the `StringSaver` documentation suggests that MUST happen for every given string.

Reviewed By: benlangmuir

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

Since GCC 11, the bundled Solaris/SPARC GCC uses the `sparcv8plus`
subdirectory for 32-bit objects, just like upstream GCC.  Before that, it
used `32` instead from a local patch.

Since `clang` doesn't know about that `sparcv8plus` subdirectory, it
wouldn't properly use GCC 11+ installations.

The new `solaris-sparc-gcc-search.test` testcase wasn't run initially (like
the existing `crash-report-null.test`) because the `.test` suffix wasn't
handled.

Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.

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

The `const char *` storage backing StringLiteral has static lifetime. Making `Twine` aware of that allows us to avoid allocating heap memory in some contexts (e.g. avoid passing it to `StringSaver::save()` in a follow-up Clang patch).

Reviewed By: benlangmuir

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

Fixed a bug where when Skelton CU had DW_AT_ranges, it the output CU DW_AT_ranges
 offset was relative, and not absolute.

Reviewed By: maksfb

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

Now that we have new DWARF Rewriter we can remove DW_AT_low_pc when converting
DW_AT_low_pc/DW_AT_high_pc to DW_AT_ranges. Which closer follows DWARF spec.
Leaving CU DW_AT_low_pc in place. Reading the spec I think it's needed.

Reviewed By: maksfb

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

Lower link clause with data entry operation.

Reviewed By: razvanlupusoru

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

This reverts commit 985486dc.

This seems to cause malformed profdata: crbug.com/1469456

This is to avoid clang-tidy complaining all over the tests that the naming is wrong.

Also rename the flag from supportsBackwardScavenger to
eliminateFrameIndicesBackwards to reflect what it actually does.

X86 is the only target still using forwards frame index elimination.
This will not block removing support for forwards register scavenging,
because X86 does not use the register scavenger.

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

This regressed in D154458 due to the added tracking of used variable
names that now also has to be cleared alongside the counter.

Reviewed By: rafaelubalmw, c-rhodes, awarzynski

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

Reviewed By: #libc, Mordante, ldionne

Spies: Mordante, libcxx-commits

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

Summary:
Older gcc can't figure out the copy elision and needs an explicit move.

This patch adds a mix-in class for the only transform op of the tensor
dialect that can benefit from one: the MakeLoopIndependentOp. It adds an
overload that makes providing the return type optional.

Reviewed By: ftynse

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

A bunch of classes in APValue free resources in the destructor but don't
have user-written copy c'tor or assignment operator, so copying them using
default ones can cause double free.

Reviewed By: aaron.ballman

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

ToolInvocation frees resources in the destructor but doesn't
have user-written copy c'tor or assignment operator, so copying it using
default ones can cause double free.

Reviewed By: aaron.ballman

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

Part of this test file was stolen from D156895. We should merge them
when committing.

Reviewed By: asb

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

Don't access leaf 7 subleaf 1 unless subleaf 0 says it is
supported via EAX.

Intel documentation says invalid subleaves return 0. We had been
relying on that behavior instead of checking the max sublef number.

It appears that some Sandy Bridge CPUs return at least the subleaf 0
EDX value for subleaf 1. Best guess is that this is a bug in a
microcode patch since all of the bits we're seeing set in EDX were
introduced after Sandy Bridge was originally released.

This is causing avxvnniint16 to be incorrectly enabled with -march=native
on these CPUs.

Reviewed By: pengfei, anna

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

This makes anlysing test failures much more easy.

For SendJSON this is simple, just use llvm::format instead.

For GetNextObject/ReadJSON it's a bit more tricky.
* Print the "Content-Length:" line in ReadJSON, but not the json.
* Back in GetNextObject, if the JSON doesn't parse, it'll be
  printed as a normal string along with an error message.
* If we didn't error before, we have a JSON value so we pretty print it.
* Finally, if it isn't an object we'll log an error for that,
  not including the JSON.

Before:
```
<--
Content-Length: 81

{"command":"disconnect","request_seq":5,"seq":0,"success":true,"type":"response"}
```

After:
```
<--
Content-Length: 81

{
  "command": "disconnect",
  "request_seq": 5,
  "seq": 0,
  "success": true,
  "type": "response"
}
```

There appear to be some responses that include strings that are themselves JSON,
and this won't pretty print those but I think it's still worth doing.

Reviewed By: wallace

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

Reviewed By: wallace

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

Previous heuristics had a big flaw: they only looked at single PHI at a time, and didn't take into account the whole "chain".
The concept of "chain" is important because if we only break a chain partially, we risk forcing regalloc to reserve twice as many registers for that vector.
We also risk adding a lot of copies that shouldn't be there and can inhibit backend optimizations.

The solution I found is to consider the whole "PHI chain" when looking at PHI.
That is, we recursively look at the PHI's incoming value & users for other PHIs, then make a decision about the chain as a whole.

The currrent threshold requires that at least `ceil(chain size * (2/3))` PHIs have at least one interesting incoming value.
In simple terms, two-thirds (rounded up) of the PHIs should be breakable.

This seems to work well. A lower threshold such as 50% is too aggressive because chains can often have 7 or 9 PHIs, and breaking 3+ or 4+ PHIs in those case often causes performance issue.

Fixes SWDEV-409648, SWDEV-398393, SWDEV-413487

Reviewed By: arsenm

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

This feature was supposed to allow you to trace execution inside of
Libomptarget. However, this never really worked properly. The printing
was always reoganized, only worked for single  threads, and pretty much
only told you a handful of things about a runtime library that's an
implementation detail to all users. Despite this, it contributed about
40% of the total filesize of the deviceRTL. This patch simply removes
this functionalit which I think was past due.

Reviewed By: tianshilei1992

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

Before this change, two equivalent operands that bufferize to a memory read and write, respectively, were always conflicting. This change improves the analysis for ops that bufferize to element-wise access. Such ops can bufferize in-place, because an original element value is not needed anymore after computing and writing an updated element value.

This change allows ops such as the following one to bufferize in-place:
```
  %0 = linalg.elemwise_binary {fun = #linalg.binary_fn<add>}
      ins(%a, %b : tensor<5xf32>, tensor<5xf32>)
      outs(%a : tensor<5xf32>) -> tensor<5xf32>
```

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

This patch adds SLEEF mappings to scalable vector functions for fmod and fmodf.

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

As detailed in Issue #57624, the introduction of
`__builtin_extract_return_address` to `GET_CALLER_PC` in
4248f32b
<https://reviews.llvm.org/rG4248f32b9ebe87c7af8ee53911efd47c2652f488> broke
`TestCases/Misc/missing_return.cpp` on Solaris/SPARC.  Unlike most other
targets, the builtin isn't a no-op on SPARC and thus has always been
necessary. Its lack had previously been worked around by calls to
`GetNextInstructionPc` in `sanitizer_stacktrace_sparc.cpp`
(`BufferedStackTrace::UnwindFast`) and `sanitizer_unwind_linux_libcdep.cpp`
(`BufferedStackTrace::UnwindSlow`).  However, those calls are superfluous
now and actually harmful.

This patch removes those hacks, fixing the failure.

Tested on `sparcv9-sun-solaris2.11` and on `sparc-sun-solaris2.11` in the
GCC tree.  On the latter, several more testcase failures had been caused by
this issue since ASan actually works with `gcc` on SPARC, unlike `clang`.

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

The errant test in the previous iteration has been corrected now.

Correct InstSimplify strictfp tests to follow the rules documented
in the LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

Some of these tests needed the strictfp attribute on function
definitions. After D154991 the constrained intrinsics have the
strictfp attribute by default so they don't need it here, but other
functions do.

Test changes verified with D146845.

Correct ShrinkWrap strictfp tests to follow the rules documented
in the LangRef:
https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics

These tests needed the strictfp attribute added to function calls.

Since I was here anyway I removed the strictfp attribute from
constrained intrinsic calls. After D154991 the constrained intrinsics
have the strictfp attribute by default so they don't need it here,
but other functions do.

Test changes verified with D146845.

This broke some bots that don't have linux/time_types.h available
(libc-x86_64-debian-*).

The header is needed because of __kernel_timespec, and since this is
only needed when SYS_sched_rr_get_interval_time64 is available, guarding
the include should fix the broken bot.

When compiling Rust code we may end up with calls to functions provided
by other code units. Presently this code crashes on a null pointer
dereference - this patch avoids that crash and adds a test.

Reviewed By: ast

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

This patch adds a bunch of ifdefs to handle the 32 bit versions of
some syscalls, which often only append a 64 to the name of the syscall
(with exception of SYS_lseek -> SYS_llseek and SYS_futex ->
SYS_futex_time64)

This patch also tries to handle cases where wait4 is not available
(as in riscv32): to implement wait, wait4 and waitpid when wait4 is
not available, we check for alternative wait calls and ultimately rely
on waitid to implement them all.

In riscv32, only waitid is available, so we need it to support this
platform.

Reviewed By: michaelrj

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

Reviewed By: ftynse

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

This reverts commit c7cacb2f.

Broken tests.

Previously lldb was storing them but not restoring them. Meaning that this function:
```
void expr(uint64_t value) {
  __asm__ volatile("msr tpidr_el0, %0" ::"r"(value));
}
```
When run from lldb:
```
(lldb) expression expr()
```
Would leave tpidr as `value` instead of the original value of the register.

A check for this scenario has been added to TestAArch64LinuxTLSRegisters.py,
which covers tpidr and the SME excluisve tpidr2 register when it's present.

Reviewed By: omjavaid

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

These instructions transfer 32 bits of data between an integer
register and half of a d-register. Currently LLVM accepts them only
with the syntax `vmov.32 r0, d0[0]` or `vmov.32 d0[0], r0`. But the
ARMARM says that the `.32` suffix on the mnemonic should be optional.

Added a pair of NEONInstAlias to accept the bare `vmov` version, and
checked that the result is the same as with `.32`.

This only adds new syntax accepted in assembly. The existing explicit
version is still used when disassembling these instructions.

Reviewed By: dmgreen

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

There was a brace that was hanging out in the middle of nowhere, this
fixes that issue.

7e229217 did live processes, this does
core files. Pretty simple, there is an NT_ARM_TLS note that contains
at least tpidr, and on systems with the Scalable Matrix Extension (SME), tpidr2
as well.

tpidr2 will be handled in future patches for SME support.

This NT_ARM_TLS note has always been present but it seems convenient to
handle it as "optional" inside of LLDB. We'll probably want the flexibility
when supporting tpidr2.

Normally the C library would set tpidr but all our test sources build
without it. So I've updated the neon test program to write to tpidr
and regenerated the corefile.

I've removed the LLDB_PTRACE_NT_ARM_TLS that was unused, we get
what we need from llvm's defs instead.

Reviewed By: omjavaid

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

Convert the elementTypeAttr of AtomicRead Op for LLVMConversion.
This is required when the elementType is non-integer, non-real.

Reviewed By: NimishMishra

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

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