When SVE2 is enabled, we can combine an add of 1, add & shift right by 1
to a single s/urhadd instruction. If the operands to the adds are extended,
these extends will fold into the s/urhadd and their costs should be 0.

Reviewed By: dtemirbulatov

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

The GFX11 scheduling model should be identical to GFX10, except for a
few tweaks to latencies.

This GFX10 change from D100123 was missed when GFX11 was added.

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

virtual is redundant if method is final.

Something with matching of quotes seems to work poorly according to
various buildbots.

Add a rough alias analysis rule for hlfir.designate which just follows
the memref argument. This could be extended in the future to take into
account the indices or derived type fields accessed to spot for provably
non-overlapping cases. In the meantime, we need a flag to ensure we
never say "MustAlias" when following a value through a hlfir.designate
because the designate analysis is only approximate.

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

These operations should have no memory effect, but doing so causes the
declare to be removed by dead code elimination if the result value is
unused. fir.declare is intended to be used to generate debug information
about variables. Debug information may still be desirable even about
unused variables, so we don't want to remove the declare operations when
performing dead code elimination.

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

Reviewed By: qcolombet

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

As with D157399 we can reduce duplication by doing this. Unlike that
patch, I'm posting the refactoring before the functional changes I want
to make here.

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

Hopefully a straightforward refactoring that reduces duplication that
was clearly causing repeated work in D157287.

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

On Mac OSX  (tested version macOS 12.4, sdk 12.1) llvm can replace call to `strrchr()` with call to `memrchr()` when string length is known at compile time. This results in link error, because `memrchr` is not present in `libSystem`. It is needed to disable this optimization in `TargetLibraryInfo` for affected OSX versions.

This non-standard function (`memrchr`) is not present on (at least) several versions of MacOS https://www.gnu.org/software/gnulib/manual/html_node/memrchr.html , so, in this patch `memrchr` is marked as unavailable for all versions. If someone knows versions where it should be available - please let me know.

Github issue: https://github.com/llvm/llvm-project/issues/62254

Tests for this feature also cannot be easily added: https://reviews.llvm.org/D134134#3801747

~~~

Huawei RRI, OS Lab

Reviewed By: nikic

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

In commit a7ee80fa a ptr->ptr bitcast was removed. But that
seem to cause "Expected an cast instruction!" assertions later in
that pass. This patch will add back the bitcast again.

This was a bit unexpected since there is no bitcast added after
creating the Add instruction in the else clause, but I guess there
is something special with the GetElementPtr scenario which makes this
bitcast needed to avoid such asserts.

This patch is also adding a reproducer for
  https://github.com/llvm/llvm-project/issues/52689
that started to fail due to hitting the above mentioned assert. Now
it should end up hitting the assertion failure from #52689 again.

This is a lot of copy-pasting for the existing handling of
G_VECREDUCE_FMAX/G_VECREDUCE_FMIN to add handling for
G_VECREDUCE_FMAXIMUM/G_VECREDUCE_FMINIMUM in the same way.

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

It is often the case that many values in the `memrefs` operand list can be
split off to speparate dealloc operations by the
`--buffer-deallocation-simplification` pass, however, the retain list has to be
preserved initially. Further canonicalization can often trim it down
considerable, but some retains may remain. In those cases, the general lowering
would be chosen, but is very inefficient. This commit adds another lowering for
those cases which avoids allocation of auxillary memrefs and the helper
function while still producing code that is linear in the number of operands of
the dealloc operation.

Reviewed By: springerm

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

Currently when widening operands for insert_subvector nodes, we check
first that the indices are valid by seeing if the subvector is
statically known to be smaller than or equal to the in-place vector.

However if we're inserting a fixed subvector into a scalable vector we rely on
the minimum vector length of the latter. This patch extends the widening logic
to also take into account the minimum vscale from the vscale_range attribute,
so we can handle more scenarios where we know the scalable vector is large
enough to contain the subvector.

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

Reviewed By: craig.topper

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

Reviewed By: olegshyshkov

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

This reverts commit 3ce43f16.

It caused MC/Disassembler/X86/x86-64.txt to fail.

This adds legalization for G_VECREDUCE_FMIN and G_VECREDUCE_FMAX, where the
selection can go via tablegen patterns. I haven't tried to get non-power2 types
working yet, just the more legal types.

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

A double colon starts an identifier name in the global namespace and
must be tentatively parsed as such.

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

wouldInstructionBeTriviallyDead is not expected to modify instruction,
so mark argument as const to allow its usage in other non-modifying instructions callers.

Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D157834

Reviewed By: XinWang10

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

D141386 changed the semantics of !range metadata to return poison
on violation. If !range is combined with !noundef, violation is
immediate UB instead, matching the old semantics.

In theory, these IR semantics should also carry over into SDAG.
In practice, DAGCombine has at least one key transform that is
invalid in the presence of poison, namely the conversion of logical
and/or to bitwise and/or (https://github.com/llvm/llvm-project/blob/c7b537bf0923df05254f9fa4722b298eb8f4790d/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L11252).
Ideally, we would fix this transform, but this will require
substantial work to avoid codegen regressions.

In the meantime, avoid transferring !range metadata without
!noundef, effectively restoring the old !range metadata semantics
on the SDAG layer.

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

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

ConversionPatterns do not (and should not) modify the type converter that they are using.

* Make `ConversionPattern::typeConverter` const.
* Make member functions of the `LLVMTypeConverter` const.
* Conversion patterns take a const type converter.
* Various helper functions (that are called from patterns) now also take a const type converter.

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

Update the `hasFlag` check to account for an Option's groups to better
match how the option parsing logic works, and instead of checking if a
group has include/exclude flags just check if there are any visible
options in it.

This cleans up some the empty sections that are currently emitted in
clang's option docs.

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

This commit ensures that debug intrinsics of killed variables do not
cause a crash of the importer. Killed locations are usually undef
constants, but in infrequent cases can also be metadata nodes, which
caused problems.

Reviewed By: zero9178

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

The newly added tests are all about scalable vector types.

Reviewed By: MaskRay

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

Reviewed By: jacquesguan

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

Reviewed By: sgraenitz

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

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

This patch match the SDNode pattern:" trunc (srem(sext, ext))" to vrem.vv. This could remove the extra "vsext" ,"vnsrl" and the "vsetvli" instructions in the case like "c[i] = a[i] % b[i]", where the element types in the array are all int8_t or int16_t at the same time.

For element types like uint8_t or uint16_t, the "zext + zext + urem + trunc" based redundant IR have been removed during the instCombine pass, this is because the urem operation won't lead to the overflowed in the LLVM.  However, for signed types, the instCombine pass can not remove such patterns due to the potential for Undefined Behavior in LLVM IR. Taking an example, -128 % -1 will lead to the Undefined Behaviour(overflowed) under the i8 type in LLVM IR, but this situation doesn't occur for i32.  To address this,  LLVM first signed extends the operands for srem to i32 to prevent the UB.

For RVV,  such overflow operations are already defined by the specification and yield deterministic output for extreme inputs. For example, based on the spec, for the i8 type, -128 % -1 actually have 0 as the output result under the overflowed situation. Therefore, it would be able to match such pattern in the instruction selection phase for the rvv backend rather than removing them in the target-independent optimization passes like instCombine pass.

This patch only handle the sign_ext circumstances for srem.  For more information about the C test cases compared with  GCC, please see : https://gcc.godbolt.org/z/MWzE7WaT4

Reviewed By: craig.topper

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

Add baseline test for [[ https://reviews.llvm.org/D156685 | D156685 ]].

In LLVM, such signed 8 bits reaminder operation will first signed extened the operands to 32 bits, and then narrow the operands to the smaller bits data type such as 16 bits during the CorrelatedValuePropagation Pass to optimize the final data storage size.

Such a signed extension operation for srem in LLVM system is to prevent the Undefined Behavior.  Taking an example, -128 % -1 will lead to the Undefined Behaviour under the i8 type in LLVM IR, but this won't happen for i32, so such pattern cannot be eliminated in the platform-independent InstCombine Pass. The LLVM IR of these sext/trunc operations will be translated one by one during the RVV backend code generation process, and redundant vsetvli instructions will be inserted.

In fact, according to the RVV instruction manual, the vrem.vv instruction has already specified the final output value of this type of overflow operation. For example, the overflow operation of -128 % -1 will get 0 according to the RISC-V spec, so through this patch , I think we can optimize these redundant rvv code through the SDNode pattern match at the instruction selection phase.

Reviewed By: craig.topper

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

Symlinks are poorly supported in Bazel+remote-exec.  Create the links from `ld.lld`,
`ld64.lld`, `lld-link`, `wasm-ld` to `lld` using LLVM's `binary_alias` instead.

Reviewed By: MaskRay

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

Reviewed By: nikic

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

Reviewed By: craig.topper

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

Since the info in MCInstrDesc is based on opcodes only, it is often quite
inaccurate. The MCInstrAnalysis has been added so that targets can provide
accurate info, which is based on registers used by the instruction, through
the own versions of MCInstrDesc functions.

The RISCVMCInstrAnalysis, which needs to refine several MCInstrDesc methods,
is a good example for this.

Given the llvm-objdump also uses MCInstrAnalysis, I think this change is in
the right direction.

The default implementation of MCInstrAnalysis methods forward the query to
MCInstrDesc functions. Hence, no functional change is intended/expected.

To avoid bloating up MCInstrAnalysis, only the methods provided by it and
the ones used by disassembler plugin are changed to use MCInstrAnalysis when
available.

Though I am not sure if it will be useful, making MCInstrAnalysis available
in the disassembler plugin would allow enabling symbolize operands (D84191)
feature in lldb's disassembler as well.

Reviewed By: jasonmolenda

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

The constants can be with larger bit width, so we need to truncate
them to EltSize or we will exceed the width of fixed-length vector.

Fixes #64588

Reviewed By: luke, craig.topper, bjope, michaelmaitland

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

There is no pattern for ADCX/ADOX and they are never selected during
ISEL. So we remove the cases in some MIR optimizations in this patch.

Reviewed By: craig.topper

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

This pass was removed in 7b560d40 almost
eight years ago and something that I forgot to cleanup when I recently
did a preliminary glance through the pass documentation in
4b5618a4.