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

When function has different attributes from module, emit the .option <attribute> before the function body.  This allows non-integrated assemblers to properly assemble the functions (which may contain instructions dependent on the extra target features).

Reviewed By: craig.topper, reames

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

CrossDSOCFIPass is supposed to replace this stub function to a properly
aligned function. However the pass is not ran if the file has no
executable code, thus producing incorrectly aligned __cfi_check.

Fixes https://github.com/llvm/llvm-project/issues/45638.

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

When generating unwind tables for code which uses return-address
signing, we need to toggle the RA_SIGN_STATE DWARF register around any
tail-calls, because these require the return address to be authenticated
before the call, and could throw an exception. This is done using the
.cfi_negate_ra_state directive before the call, and .cfi_restore_state
at the start of the next basic block.

However, since D153098, the .cfi_restore_state isn't being inserted,
because the CFIFixup pass isn't being run. This re-enables that pass
when return-adress signing is enabled.

Reviewed By: ikudrin, MaskRay

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

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

To match GCC.

Options `-m[no-]strict-align` are aliases of `-m[no-]unaligned-access`
in clang, but there is no corresponding option in GCC.

Support of `-m[no-]unaligned-access` in GCC may be needed to align
Clang/GCC.

Reviewed By: kito-cheng

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

Reviewed By: craig.topper

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

Also make `getNumDynamicEntriesUpToIdx` a helper function. It does not have to be an interface method.

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

IDs of the note list start from 1. Link generated for each note started
with index 0 i.e #Note0, #Note1 and so on.
As a result, first link ("#Note0") was invalid, subsequent links pointed
at wrong note.
Now, generated links to the notes start with index 1 i.e (#Note1, #Note2
and so on.

Patch by Guruprasad Hegde (gruuprasad)!

Fixes https://github.com/llvm/llvm-project/issues/64054

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

This is for consistency with the remaining MLIR code base.

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

Wrong error message is fixed and a note of argument is printed.

Tests are added in `llvm/test/TableGen/template-args.td`.

Reviewed By: DavidSpickett

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

Backwards frame index elimination uses backwards register scavenging,
which is preferred because it does not rely on accurate kill flags.

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

[X86] combineAnd - limit and(extract_vector_elt(shuffle(x)) -> extract_vector_elt(shuffle'(x)) fold to one use of the extract_vector_elt.

Prevents a regression in an upcoming patch.