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 i...

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.

Unlike isa<> and cast<>, current implementation of dyn_cast<> fails
to process a std::unique_ptr to a class supporting LLVM RTTI:

// A and B support LLVM RTTI
class A {...}
class B: public A {...}

void foo() {
...
  auto V = std::make_unique<A>();
  auto VB = dyn_cast<B>(std::move(V));
  if (VB)
    ...
...
}

Reviewed By: lattner, bzcheeseman

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

Before https://github.com/llvm/llvm-project/commit/cae84d8acf5ec7a8f7b9fd2ce33397bcc22c590c all __linux__ checks were incorrectly __unix__ checks. __unix__ being true on macOS systems therefore meant that macOS would use 65 as __UTS_NAME_LENGTH.

This commit correctly specifices __UTS_NAME_LENGTH to match XNU as 256.
https://opensource.apple.com/source/xnu/xnu-201/bsd/sys/utsname.h.auto.html

Reviewed By: thesamesam

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

This header contains implementation specific constants.

The compiler already provides its own limits.h with numerical limits
conforming to freestanding ISO C. But it is missing extensions like
POSIX, and does for example not include <linux/limits.h> which is
expected on a Linux system, therefore, an LLVM libc implementation of
limits.h is needed for hosted (__STDC_HOSTED__) environments.

Reviewed By: michaelrj

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

Revert "Reapply: [MemCpyOpt] implement single BB stack-move optimization which unify the static unescaped allocas"

Fails on https://lab.llvm.org/buildbot/#/builders/85/builds/18296

This reverts commit 43698c1d.

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

This fixes https://github.com/llvm/llvm-project/issues/60766

With MSVC style exception-handling (funclets), no registers are
alive when entering the funclet so they must be reloaded from the
stack.  MachineLICM can sometimes hoist such reloads out of the
funclet which is not correct, the register will have been clobbered
when entering the funclet.  This can happen in any loop that
contains a try-catch.

This has been tested on x86_64-pc-window-msvc.  I'm not sure if
funclets work the same on the other windows archs.

Reviewed By: rnk, arsenm

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