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

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

The last dependency of code defined in LoopVectorize.cpp has been
removed a while ago. Move VPTransformState::get() to VPlan.cpp where
other members are also defined.

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

OpInterface inheritance will duplicate base interfaces, causing compilation failure.  Unique the set of base interfaces.

Reviewed By: rriddle, jdd

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

Summary:
In cases where the PC has no function name, lldb-vscode crashes.

`lldb::SBFrame::GetDisplayFunctionName()` returns a `nullptr`, and when we
attempt to construct an `std::string`, it raises an exception.

Test plan:
This can be observed with creating a test file (credit to @clayborg for
the example):
```
int main() {
  typedef void (*FooCallback)();
  FooCallback foo_callback = (FooCallback)0;
  foo_callback(); // Crash at zero!
  return 0;
}
```
and attempting to debug the file through VSCode.

I add a test case in D156732 which should cover this.

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

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

The copyprivate clause is not yet implemented. Provide a TODO
error message when this clause is seen.

Reviewed By: NimishMishra

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

Tweak the immediate on two vror.vi test cases to use a uimm6 immediate
that would have failed before D156974 when we were looking for a simm6
immediate.

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.