We have now seen two miscompiles because of widening widenable
conditions at incorrect IR points and thereby changing a branch's loop
invariant condition to a loop-varying one (see PR60234 and PR61963).

This patch adds asserts in common guard utilities that we use for
widening to proactively catch these bugs in future.
Note that these asserts will not fire if we were to sink a widenable
condition from out of a loop into a loop (that's also incorrect for the
same reason as above).

Tested this without the fix for PR60234 (guard widening miscompile) and
confirmed the assert fires.

WARNING: Sometimes, the assert can fire if we failed to hoist the
invariant condition out of the loop. This is a pass-ordering issue or a
limitation in LICM, which would need an investigation. See details in
review.

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

Update the planning code constructing VPlan to allow building VPlans to
fail. This allows us to gradually shift some legality checks to VPlan
construction. The first candidate is checking if all users of
first-order recurrence phis can be sunk past the recipe computing the
previous value.

The new functionality will be used by D142886 which is approved and will
be landed shortly.

Reviewed By: Ayal

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

Fix the test introduced in D136592 which appeared to have a few check lines
containing an un-checked prefix "GISEL-GFX".
Also canonicalize the other prefixes to minimize churn if SDag and GISel
diverge.

Reviewed By: arsenm

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

Ceilf are pushed directly to libm. This is problematic for
situations where libm is not available. This patch will break down
a ceilf function to truncate followed by an increment if the
truncated value is smaller than the input value.

Reviewed By: rsuderman

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

If a gather/scatter is masked and will need to be scalarized then the cost
should be higher than we currently produce. An additional cost for scalarizing
the mask, extracting i1s and branching on the result needs to be added, which
this patch gives a cost of 5.

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

This shows up in the wild, notably as a regression in D127115 .

Depends on D147821

Reviewed By: RKSimon

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

Simplify the range reduction steps by choosing the reduction constants
carefully so that the reduced arguments v = r*m_x - 1 and v^2 are exact in double
precision, even without FMA instructions, and -2^-8 <= v < 2^-7.

Reviewed By: zimmermann6

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

Reviewed By: aheejin

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

[X86] Remove unnecessary OneUse limit from combineToExtendBoolVectorInReg (vXi1 bitcast(iX Cond)) select expansion

We already allow multiple uses when calling from combineSext/combineZext - adding hasOneUse seems to have been a copy+paste from some of the similar AVX512 vselect folds.

Fixes #62014

I've found that a frequent source of debug information loss in optimized
code is due to DEBUG_VALUE intrinsics in a position of the instruction
stream that is outside the scope of the variable it describes.

Tracking these is pretty difficult with the existing debug messages of
the history calculator; this patch addresses the issue by making it
obvious when this event happens.

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

This is ok as we build the libraries with `-ffreestanding` which implies `-fno-builtin` on all functions.

This reverts commit 070233da.

It also reverts follow-ups 2588e831 and
027f60a6.

Fixed two test cases that relied on Asserts, and added a fallthrough
annotation to the switch case.

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

This limitation was discovered thanks to some regression in D127115 .

Reviewed By: RKSimon

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

Ensure we test different vector element sizes

vector-bo-select.ll should only be used for binop identity select tests

These methods can be called with an O0 level nowadays.

Reviewed By: gribozavr2

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

In the non-ThinLTO pipeline this was directly before PipelineStartEP,
in the ThinLTO pipeline it was directly after. I don't think the
specific position matters here, just make sure it's the same for
both pipelines.

buildModuleSimplificationPipeline() is not used for O0.

The math libraries have a lot of code that performs
manual sign bit operations by bitcasting doubles to int2
and doing bithacking on them. This is a bad canonical form
we should rewrite to use high level sign operations directly
on double. To avoid codegen regressions, we need to do a better
job moving fnegs to operate only on the high 32-bits.

This is only halfway to fixing the real case.

Added multiuse checks for v8i16 and v8f32 cases

Ops from the Math dialect use fastmath attributes defined in Arith.
Therefore Math dialect must declare a dependency on Arith for proper
construction and parsing.

Reviewed By: tpopp

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

Avoid divergence b/w different kinds of hoisting with reassociation.
Make them all collect general stat NumHoisted and also specific stats
for each particular transform.

Reviewed By: MatzeB

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

They all are now handled by hoistArithmetics, and only it should be
forwarded.

Should not optimize here because no-overflow is not proved.