We were relying on a transitive include. This fixed
building the SPIRV backend.

Problem seem to be that on windows it says
  "Assertion failed: ...."
while one linux we get
  "Assertion ... failed."

Anyway, this fixup also limits the test case to x86_64-linux to
avoid buildbot failures due to such problems.

If the only purpose of the upgrade is a mangling change, this is
handled generically by intrinsic remangling, and does not require
any hand-written code.

This patch enables logical expressions to be used as arguments when the
default logical kind is changed (e.g. using -fdefault-integer-8) by
converting the type of the logical expression argument to the type of
the dummy argument in the function.

Reviewed By: klausler

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

Add two new helper functions `getBeforeBody` and `getAfterBody` to be consistent with "scf.for" (`getBody`) and to show in the API that both regions have exactly one block. Also simplify some code that assumed that there can be more than one block in a region.

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

When inspecting the function body, we can't simply ignore effects
of functions in the SCC entirely, because an argmem access of a
recursive call might result in an access to another location in
the callee.

Fix this by separately tracking memory effects that would occur if
the SCC accesses argmem, and then later add those.

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

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

If an argument is readnone we know that it isn't dereferenced. Then
it should be OK if that argument alias with a noalias argument.

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

WgmmaMmaAsync Op generates `wgmma.mma_async` PTX instruction that uses the same registers as read and write with mapping. Therefore, the registers count needs to be increased 2 times for the following registers.

This works changes this:
```
llvm.inline_asm has_side_effects asm_dialect = att "{wgmma.mma_async... {$0, $1, $2, $3, $4}, $5, $6, p", "=f,=f,=f,=f,0,1,2,3,l,l"
```

Into this one below. The only different is the number of registers ($8 and $9) that comes after read/write.
```
llvm.inline_asm has_side_effects asm_dialect = att "{wgmma.mma_async... {$0, $1, $2, $3, $4}, $8, $9, p", "=f,=f,=f,=f,0,1,2,3,l,l"
```

Reviewed By: qcolombet

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

Without the fix gcc complains with:
../utils/TableGen/GlobalISelCombinerMatchTableEmitter.cpp:251:60: warning: suggest parentheses around '&&' within '||' [-Wparentheses]

This fixes a failure from the expensive-checks buildbot

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

This addresses issues found by:
https://lab.llvm.org/buildbot/#/builders/30/builds/38760

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

This reverts commit dda2cd25.

As discussed on #46593 - this enables us to use __lzcnt / __popcnt intrinsics inside constexpr code.

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

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