We would not ensure that the error is consumed in the case that logging
is disabled. Ensure that we properly drop the error on the floor or we
would re-trigger the checked failure.

Differential Revision: https://reviews.llvm.org/D147669
Reviewed By: sgraenitz

Use the assembly format with custom parser/printer
for specific clauses instead of a full custom parser/printer.

Reviewed By: PeteSteinfeld

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

Don't cast the pointers to long, as that's not large enough for
pointers on 64 bit Windows.

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

Summary:
The `nvlink` linker doesn't support static libraries, so we just pass in
the object files. The condition was erroneously doing this for every
single GPU architecture and not just NVIDIA. The AMDGPU support handles
static libraries just fine.

Summary:
We need a dependency here so the loader is up-to-date whenever we run
the tests again.

Both Linux and LiteOS for all OpenHarmony targets use emulated TLS

~~~

Huawei RRI, OS Lab

Reviewed By: DavidSpickett, jrtc27, MaskRay

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

When a cold function is too large, its section gets deregistered.
However, the section is still dereferenced later to get its RuntimeDyld
ID. This patch moves the deregistration to after the last dereference.

Reviewed By: Amir

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

This attempts to resolve the issue found by:
https://lab.llvm.org/buildbot/#/builders/139/builds/39296

This patch precommits a test for:

https://reviews.llvm.org/D148420

This patch fixes the wrong signal from the constexpr evaluator that
[[gnu::weak]] member pointer comparison is valid, while it is emitting
notes on them.

I found a crashing case fixed by this change and added it as a test
case: https://godbolt.org/z/8391fGjGn

I noticed this while I was working on D146358.

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

We can't branch directly to the EH pad, which is what the current
loop deletion code would try to do. We would need a different
approach here, which retains the invoke. This edge case does not
look worth bothering with.

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

Matches the equivalent EVT::getDoubleNumVectorElementsVT helper.

This allows us to consistently MVT instead of EVT in the combinePTESTCC method.

This patch adds a new trait to allow standard libraries to forward `std::equal` calls to `memcmp` in more cases.

Reviewed By: aaron.ballman

Spies: Mordante, shafik, xbolva00, libcxx-commits, cfe-commits, ldionne

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

By the ConvertToFIR pass, the hlfir.get_shape operation will have been
lowered into a fir.shape operation (during the HFLIR bufferization pass)
and so, lowering get_extent is as simple as fetching the extent from the
shape operation.

Depends on: D146833

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

If possible the shape is gotten from the bufferization of the expr
argument.

The simple cases should already have been resolved during lowering. This
is mostly intended for cases where shape information is added in between
lowering and the end of bufferization (for example transformational
intrinsics with assumed shape arguments).

Depends on: D146832

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

If the extents were known, this should have been canonicalised into a
fir.shape operation. Therefore, the extents at this point are not known at
compile time. Use hlfir.get_extents to delay resolving the real extent
until after the expression is bufferized.

Depends On: D146831

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

Depends On: D146830

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

This operation fetches an extent value from a fir.shape. The operation
could just as easily live in the fir namespace, but is only needed for
hlfir lowering so I put it here.

This operation is required to allow one to defer getting the extents of a shape
generated by hlfir.get_shape until after that shape has been resolved
(after bufferization of the hlfir.expr).

This operation will be lowered to FIR as an arith.constant created using
the definition of the fir.shape argument.

Depends on: D146830

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

This is an operation which returns the fir.shape for a hlfir.expr.

A hlfir.expr can be defined by:
  - A transformational intrinsic (e.g. hlfir.matmul)
  - hlfir.as_expr
  - hlfir.elemental

hlfir.elemental is easy because there is a compulsory shape operand.
hlfir.as_expr is defined as operating on a variable (defined using a
hlfir.declare). hlfir.declare has an optional shape argument. The
transformational intrinsics do not have an associated shape.

If all extents are known at compile time, the extents for the shape can
be fetched from the hlfir.expr's type. For example, the result of a
hlfir.matmul with arguments who's extents are known at compile time will
have constant extents which can be queried from the type. In this case
the hlfir.shape_of will be canonicalised to a fir.shape operation using
those extents.

If not all extents are known at compile time, shapes have to be read
from boxes after bufferization. In the case of the transformational
intrinsics, the shape read from the result box can be queried from the
hlfir.declare operation for the buffer allocated to that hlfir.expr (via
the hlfir.as_expr).

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

This patch standardizes the error messages when a syscall is not
available to be in the format: "ABC and DEF syscalls are not available."

Reviewed By: sivachandra

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

[X86] combinePTESTCC - fold TESTZ(OR(LO(X),HI(X)),OR(LO(Y),HI(Y))) -> TESTZ(X,Y) for TESTPS/TESTPD ops

Followup to the fix for #62171, adding support for TESTPS/TESTPD opcodes

Reviewed By: fakepaper56

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

This avoids conflicts when regenerating check lines.

After recent improvements, all instances of
VPWidenIntOrFpInductionRecipe should needs a vector IV and there's no
need for a separate field.

In some cases non-null non-constant yet valid expression may reach point where
`ConditionResult` is created. For example, typo correction mechanism can return
such expression, so double check before evaluating it.

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

Reviewed By: tbaeder, aaron.ballman

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

This reverts commit 981ec1fa.

It broke polly build bots. Polly still uses -instnamer with legacy PM.

This exposed a miscompile in GVN, which was fixed by D148129.

-----

After D141386, violation of nonnull, range and align metadata
results in poison rather than immediate undefined behavior,
which means that these are now safe to retain when speculating.
We only need to remove UB-implying metadata like noundef.

This is done by adding a dropUBImplyingAttrsAndMetadata() helper,
which lists the metadata which is known safe to retain on speculation.

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

Extra coverage for D143604, D143605.

The following intrinsics are currently implemented using a shufflevector with
an undefined mask, this is however incorrect according to intel's semantics for
undefined value which expect an unknown but consistent value.

With __builtin_nondeterministic_value we can now match intel's undefined value.

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

Removed definitions of vectorizeBasicBlock and VectorizeConfig
(possibly a remnant from the BBVectorize pass that was removed
way back in 2017).

Also reduced amount of include dependencies to Transforms/Vectorize.h.

Mostly removing includes of InitializePasses.h and Pass.h in
passes that no longer has support for the legacy PM.

The argument name 'useBarePtrCallConv' does not match the actual
parameter name 'useBarePointerCallConv'.

Add support for FirstOrderRecurrenceSplice and VPFirstOrderRecurrencePHI
recipes to mayHaveSideEffects. They both don't have side-effects.

As pointed out in D148010, these passes are missing from the LTO
post-link pipeline. They are present in the pre-link pipeline,
but LoopSink is completely useless there (it will always be fully
undone by LICM post-link) and DivRemPairs is mostly useless
(I believe most of what it does will be undone by InstCombine).

I've not added RelLookupTableConverterPass, because it's also
disabled in the LTO pre-link pipeline, with a comment that there
is an unresolved issue with full LTO.

Compile-time impact of the extra passes is minimal. Of course,
LoopSink will have a larger impact in PGO builds.

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

This reverts commit 2c8d0048.

This is incorrect: computeKnownFPClass() is only known up to
poison, and freeze poison may have any FP class.

This ensures VPlan-based DCE won't be able to remove the unused
recurrences.

It also adds a dedicated new test (@unused_recurrence) where an unused
recurrence can be removed.

When reusing a load in a way that requires coercion (i.e. casts or
bit extraction) we currently fail to adjust metadata. Unfortunately,
none of our existing tooling for this is really suitable, because
combineMetadataForCSE() expects both loads to have the same type.
In this case we may work on loads of different types and possibly
offset memory location.

As such, what this patch does is to simply drop all metadata, with
the following exceptions:

* Metadata for which violation is known to always cause UB.
* If the load is !noundef, keep all metadata, as this will turn
  poison-generating metadata into UB as well.

This fixes the miscompile that was exposed by D146629.

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

In LoopVectorizationCostModel::isEpilogueVectorizationProfitable we
check to see if the chosen main vector loop VF >= 16. If so, we
decide to create a vector epilogue loop. However, this doesn't
take VScaleForTuning into account because we could be targeting a
CPU where vscale > 1, and hence the runtime VF would be a multiple
of the known minimum value.

This patch multiplies scalable VFs by VScaleForTuning and several
tests have been updated that now produce vector epilogues.

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