Fusion of generic/indexed_generic operations with tensor_reshape by
expansion when the latter just adds/removes unit-dimensions is
disabled since it just adds unit-trip count loops.

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

Reviewed By: asb, frasercrmck

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

Reviewed By: asb, frasercrmck

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

These instructions use a portion of the encodings for grevi and
gorci. The full encodings are only supported with Zbp. Note,
rev8 has a different encoding between rv32 and rv64.

Zbb is closer to being finalized that Zbp which has motivated
some decisions in this patch.

I'm treating rev8 and orc.b as separate instructions when
either Zbb or Zbp is enabled. This allows us to print to suggest
that either feature needs to be enabled to support these mnemonics.
I had tried to put HasStdExtZbbAndNotZbp on the Zbb instructions,
but that caused a diagnostic that said Zbp is required if neither
feature is enabled. We should really mention Zbb since its closer
to final.

This does require extra isel patterns for the different cases so
that bswap will always print as rev8 in assembly listing since
we can't use an InstAlias.

llvm-objdump disassembling should always pick the rev8 or orc.b
instructions. llvm-mc parsing and printing text will not convert
the grevi/gorci spellings to rev8/gorc.b. We could probably fix
this with a special case in processInstruction in the assembly
parser if it its important.

Reviewed By: asb, frasercrmck

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

zext.h uses the same encoding as pack rd, rs, x0 in rv32 and
packw rd, rs, x0 in rv64. Encodings without x0 as the second source
are not valid in Zbb.

I've added two new instructions with these specific encodings with
predicates that enable them when either Zbb or Zbp is enabled.

The pack spelling will only be accepted with Zbp. The disassembler
will use the zext.h instruction when either feature is enabled.

Using the pack spelling will print as pack when llvm-mc is
emitting text. We could fix this with some custom code in
processInstruction if this is important, but I'm not sure it is.

Reviewed By: asb, frasercrmck

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

Zext.h will need to come back to Zbb, but that only uses specific
encodings of pack.

Reviewed By: asb, frasercrmck

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

This didn't make it into the published 0.93 spec, but it was the
intention.

But it is in the tex source as of this commit
https://github.com/riscv/riscv-bitmanip/commit/d172f029c074d47026a0c0d0f12d8b475c86a472

This means zext.w now requires Zba. Not sure if we should still use
pack if Zbp is enabled and Zba isn't. I'll leave that for the future
when pack is closer to being final.

Reviewed By: asb, frasercrmck

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

The 0.93 spec has this implementation for add.uw

uint_xlen_t adduw(uint_xlen_t rs1, uint_xlen_t rs2) {
  uint_xlen_t rs1u = (uint32_t)rs1;
  return rs1u + rs2;
}

The 0.92 spec had the usages of rs1 and rs2 swapped.

Reviewed By: frasercrmck, asb

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

Also renamed Zbe instructions to resolve name conflict even though
that change is in the 0.94 draft.

Reviewed By: asb, frasercrmck

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

It's not really clear in the spec that these are in Zbp now, but
that's what I've gather from previous commits to the spec. I've
file an issue to get it documented properly.

Reviewed By: asb, frasercrmck

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

Reviewed By: asb, frasercrmck

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

Still need to add SH*ADD instructions.

Reviewed By: asb, frasercrmck

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

Reviewed By: asb, frasercrmck

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

Reviewed By: asb, frasercrmck

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

Reviewed By: asb, frasercrmck

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

This is the first of multiple patches to bring our 0.92
implementation up to 0.93.

Reviewed By: asb, frasercrmck

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

Willreturn would be inferred by FuncAttrs for these. Annotate them
to preserve test behavior in the future.

The legacy PM's EP_CGSCCOptimizerLate was only used under not-O0.

Fixes clang/test/CodeGenCXX/cxx0x-initializer-stdinitializerlist.cpp under the new PM.

Reviewed By: arsenm

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

It has the low-level bit fiddling operations from bit. It eliminates a cyclic dependency between __bit_reference, bits, and vector. I want to exploit this in later patches.

Reviewed By: #libc, ldionne

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

Most of CGExprConstant.cpp is using the CharUnits abstraction
and is using getCharWidth() (directly of indirectly) when converting
between size of a char and size in bits. This patch is making that
abstraction more consistent by adding CharTy to the CodeGenTypeCache
(honoring getCharWidth() when mapping from char to LLVM IR types,
instead of using Int8Ty directly).

Reviewed By: rjmccall

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

When using getByteArrayType the requested size is calculated in
char units, but the type used for the array was hardcoded to the
Int8Ty. This patch is using getCharWIdth a bit more consistently
by using getIntNTy in combination with getCharWidth, instead
of explictly using getInt8Ty.

Reviewed By: rjmccall

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

This revision adds support for using either operand or result types to anchor an optional group. It also removes the arbitrary restriction that type directives must refer to variables in the same group, which is overly limiting for a declarative format syntax.

Fixes PR#48784

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

Remove a few of my own TODOs that I will not have time to fix from lit
code.

If the call result is unused, we should let it get DCEd rather
than replacing it. Also, don't try to replace an existing sincos
with another one (unless it's as part of combining sin and cos).

This avoids an infinite combine loop if the calls are not DCEd
as expected, which can happen with D94106 and lack of willreturn
annotation in hand-crafted IR.

This is meant to unblock Chrome, as discussed in https://llvm.org/D74489.

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

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

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

During the review of https://reviews.llvm.org/D93912 we failed to notice
the implementation status wasn't updated. This rectifies the issue.

representing dependence from producer result to consumer.

With Linalg on tensors the dependence between operations can be from
the result of the producer to the consumer. This change just does a
NFC refactoring of the LinalgDependenceGraphElem to allow representing
both OpResult and OpOperand*.

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

Adding a lld option to support emitting pseudo probe metadata in LTO mode.

Reviewed By: MaskRay, wmi, wenlei

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

* Remove an unimplemented and unused member function declaration
* Remove a misleading comment about an unrelated constraint number
* Fix a comment
* Add f18 crash message to "flang" driver script

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

This is a continuation of https://reviews.llvm.org/D94239. I missed some other spellings of the same error.

Reviewed By: muiez

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

Correct the analysis of references to transformational intrinsic
functions that have different semantics based on the presence or
absence of a DIM= argument; add shape analysis for UNPACK().

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

In the motivating cases from https://llvm.org/PR48816 ,
we have a trailing trunc. But that is not required to
reduce the abs width:
https://alive2.llvm.org/ce/z/ECaz-p
...as long as we clear the int-min-is-poison bit (nsw).

We have some existing tests that are affected, and I'm
not sure what the overall implications are, but in general
we favor narrowing operations over preserving nsw/nuw.

If that causes problems, we could restrict this transform
based on type (shouldChangeType() and/or vector vs. scalar).

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

https://llvm.org/PR48816

spv.Ordered/spv.Unordered are meant for OpenCL Kernel capability.
For Vulkan Shader capability, we should use spv.IsNan to check
whether a number is NaN.

Add a new pattern for converting `std.cmpf ord|uno` to spv.IsNan
and bumped the pattern converting to spv.Ordered/spv.Unordered
to a higher benefit. The SPIR-V target environment will properly
select between these two patterns.

Reviewed By: mravishankar

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

Expressions emitted to module files and error messages
sometimes contain conversions of integer results of inquiry
intrinsics; these are usually not needed, and can conflict
with "int" in the user's namespace.  Improve folding so that
these conversions don't appear, and do some other clean-up
in adjacent code.

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

Previously we only autogen the availability for ops that are
direct instantiating `SPV_Op` and expected other subclasses of
`SPV_Op` to define aggregated availability for all ops. This is
quite error prone and we can miss capabilities for certain ops.
Also it's arguable to have multiple levels of subclasses and try
to deduplicate too much: having the availability directly in the
op can be quite explicit and clear. A few extra lines of
declarative code is fine.

Reviewed By: mravishankar

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

ObjCBOOLSummaryProvider was incorrectly treating BOOL as unsigned and this is now fixed.
Also adding tests for one bit bit-fields of BOOL and unsigned char.

This PR only has coro intrinsics needed for the Async to LLVM lowering. Will add other intrinsics as needed in the followup PRs.

Reviewed By: mehdi_amini

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