Depends on D88415

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

File-granular information is considered details.

Depends on D88411

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

File-granular information is considered details.

Depends on D88411

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

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

A structure that can be used to represent memory usage of a nested
set of systems.

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

Based on a discussion on D88783, if we're promoting a funnel shift to a width at least twice the size as the original type, then we can use the 'double shift' patterns (shifting the concatenated sources).

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

Reviewed By: herhut

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

VE doesn't have instruction for copysign, so expand it.  Add a
regression test also.

Reviewed By: simoll

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

This is essentially a replacement for the PacketUnimplementedError
previously present in the gdb-remote server code.

The reason I am introducing a generic error is because I wanted the
native process classes to be able to signal that they do not support
some functionality. They could not use PacketUnimplementedError as they
are independent of a specific transport protocol. Putting the error
class in the the native process code was also not ideal because the
gdb-remote code is also used for lldb-server's platform mode, which does
not (should not) know how to debug individual processes.

I'm putting it under Utility, as I think it can be generally useful for
notifying about unsupported/unimplemented functionality (and in
particular, for programatically testing whether something is
unsupported).

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

The tracer is now expected to allocate+free the args itself.

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

Only SymbolFileDWARF::ParseCompileUnit creates a CompileUnit and it uses
DWARFCompileUnit for that.

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

This revision reduces the number of places that specific information needs to be modified when adding new named Linalg ops.

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

This revision introduces support for buffer allocation for any named linalg op.
To avoid template instantiating many ops, a new ConversionPattern is created to capture the LinalgOp interface.

Some APIs are updated to remain consistent with MLIR style:
`OwningRewritePatternList * -> OwningRewritePatternList &`
`BufferAssignmentTypeConverter * -> BufferAssignmentTypeConverter &`

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

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

Currently the idiom for mapping optional fields is:
  ObjectMapper O(Val, P);
  if (!O.map("required1", Out.R1) || !O.map("required2", Out.R2))
    return false;
  O.map("optional1", Out.O1); // ignore result
  return true;

If `optional1` is present but malformed, then we won't detect/report
that error. We may even leave `Out` in an incomplete state while returning true.
Instead, we'd often prefer to ignore `optional1` if it is absent, but otherwise
behave just like map().

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

Revert rGb97093e5 - "[InstCombine] matchFunnelShift - fold or(shl(a,x),lshr(b,sub(bw,x))) -> fshl(a,b,x) iff x < bw"

This reverts commit b97093e5.

Funnel shift argument commutation isn't working correctly

VE doesn't have fneg or frem instruction, so change them to expand.  Add
regression tests also.

Reviewed By: simoll

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

VE doesn't have BRCOND instruction, so need to expand it.  Also add
a regression test.

Reviewed By: simoll

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

Summary: Since willreturn will soon be added as default attribute, we can end up with both noreturn and willreturn on the same intrinsic. This was exposed by llvm.wasm.throw which has IntrNoReturn.

Reviewers: jdoerfert, arsenm

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

The dependent mechanism for C error-recovery is mostly finished,
this is the only place we have missed.

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

See whole context: https://reviews.llvm.org/D85025

Reviewed By: sammccall

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

Specification for `SHT_HASH` table says (https://refspecs.linuxbase.org/elf/gabi4+/ch5.dynamic.html#hash)
that it contains `Elf32_Word` entries for both `32/64` bit objects.

But there is a problem with `EM_S390` and `ELF::EM_ALPHA` platforms: they use 8-bytes entries.
(see the issue reported: https://bugs.llvm.org/show_bug.cgi?id=47681).

Currently we might infer the size of the dynamic symbols table from hash table,
but because of the issue mentioned, the calculation is wrong. And also we don't dump the hash table
properly.

I am not sure if we want to support 8-bytes entries as they violates specification and also the
`.hash` table is kind of deprecated by itself (the `.gnu.hash` table is used nowadays).
So, the solution this patch suggests is to ban using of the hash table on `EM_S390/EM_ALPHA` platforms.

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

Given the following VarTemplateDecl AST,

```
VarTemplateDecl col:26 X
|-TemplateTypeParmDecl typename depth 0 index 0
`-VarDecl X 'bool' cinit
  `-CXXBoolLiteralExpr 'bool' true
```

previously, we returned the VarDecl as the top-level decl, which was not
correct, the top-level decl should be VarTemplateDecl.

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

This reverts commit df295fac.

Reactivates a spuriously rolled back change.

The buffer placement preparation tests in
test/Transforms/buffer-placement-preparation* are using Linalg as a test
dialect which leads to confusion and "copy-pasta", i.e. Linalg is being
extended now and when TensorsToBuffers.cpp is changed, TestBufferPlacement is
sometimes kept in-sync, which should not be the case.

This has led to the unnoticed bug, because the tests were in a different directory and the patterns were slightly off.

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

While we indeed can't treat them as no-ops, i believe we can/should
do better than just modelling them as `unknown`. `inttoptr` story
is complicated, but for `ptrtoint`, it seems straight-forward
to model it just as a zext-or-trunc of unknown.

This may be important now that we track towards
making inttoptr/ptrtoint casts not no-op,
and towards preventing folding them into loads/etc
(see D88979/D88789/D88788)

Reviewed By: mkazantsev

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

I have introduced a new template PolySize class, where the template
parameter determines the type of quantity, i.e. for an element
count this is just an unsigned value. The ElementCount class is
now just a simple derivation of PolySize<unsigned>, whereas TypeSize
is more complicated because it still needs to contain the uint64_t
cast operator, since there are still many places in the code that
rely upon this implicit cast. As such the class also still needs
some of it's own operators.

I've tried to minimise the amount of code in the base PolySize
class, which led to a couple of changes:

1. In some places we were relying on '==' operator comparisons
between ElementCounts and the scalar value 1. I didn't put this
operator in the new PolySize class, and thought it was actually
clearer to use the isScalar() function instead.
2. I removed the isByteSized function and replaced it with calls
to isKnownMultipleOf(8).

I've also renamed NextPowerOf2 to be coefficientNextPowerOf2 so
that it's more consistent with coefficientDivideBy.

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

Let user able to know which -tune-cpu are used now.

Reviewed By: craig.topper

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

This reverts commit b5a034e7.

This feature was added without following the proper process.

This reverts commit 849c6054 because it
results in a stage 2 build failure:

llvm-project/clang/include/clang/AST/ExternalASTSource.h:409:20: error:
definition with same mangled name
'_ZN5clang25LazyGenerationalUpdatePtrIPKNS_4DeclEPS1_XadL_ZNS_17ExternalASTSource19CompleteRedeclChainES3_EEE9makeValueERKNS_10ASTContextES4_'
as another definition

  static ValueType makeValue(const ASTContext &Ctx, T Value);

fp-strict-conv-f128.ll is generated by script, but some manual MIR tests
exist in it. Move them to another file to satisfy script when updating.