Adapt the implementation of TransformEachOpTrait to the existence of
parameter values recently introduced into the transform dialect. In
particular, allow `applyToOne` hooks to return a list containing a mix
of `Operation *` that will be associated with handles and `Attribute`
that will be associated with parameter values by the trait
implementation of the transform interface's `apply` method.

Disentangle the "transposition" of the list of per-payload op partial
results to decrease its overall complexity and detemplatize the code
that doesn't really need templates. This removes the poorly documented
special handling for single-result ops with TransformEachOpTrait that
could have assigned null pointer values to handles.

Reviewed By: springerm

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

It was originally placed in TransformInterfaces for convenience, but it
is really a generic utility. It may also create an include cycle between
TransformTypes and TransformInterfaces if the latter needs to include
the former because the former uses the failure util.

Reviewed By: springerm

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

This makes it more consistent with the recently added
TransformParamTypeInterface.

Reviewed By: springerm

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

Introduce a new kind of values into the transform dialect -- parameter
values. These values have a type implementing the new
`TransformParamTypeInterface` and are associated with lists of
attributes rather than lists of payload operations. This mechanism
allows one to wrap numeric calculations, typically heuristics, into
transform operations separate from those at actually applying the
transformation. For example, tile size computation can be now separated
from tiling itself, and not hardcoded in the transform dialect. This
further improves the separation of concerns between transform choice and
implementation.

Reviewed By: springerm

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

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

This pattern is similar to `FoldFillWithTensorReshape`, which performs the same swapping with reshapes.

Fill the smaller extracted tensor slice instead of `x`. This allows for additional simplifications in case `x` is the result of another extract_slice.

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

The stream handling functions `ftell`, `rewind`, `fgetpos`, `fsetpos`
are evaluated in the checker more exactly than before.
New tests are added to test behavior of the checker together with
StdLibraryFunctionsChecker. The option ModelPOSIX of that checker
affects if (most of) the stream functions are recognized, and checker
StdLibraryFunctionArgs generates warnings if constraints for arguments
are not satisfied. The state of `errno` is set by StdLibraryFunctionsChecker
too for every case in the stream functions.
StreamChecker works with the stream state only, does not set the errno state,
and is not dependent on other checkers.

Reviewed By: Szelethus

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

When feature CSSC is available we should use instruction CNT for s32, s64 and
s128 types in GlobalIsel's G_CTPOP.

spec:
https://developer.arm.com/documentation/ddi0602/2022-09/Base-Instructions/CNT--Count-bits-

Reviewed By: aemerson

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

This may cause GlobalSplit to fail if opaque pointers are used.

inrange really needs a new representation, but for now restore the
pre-opaque pointers status.

This patch adds metadata to disable runtime unrolling to the vectorized
loop. If runtime unrolling/interleaving is considered profitable, LV
will interleave the loop directly. There should be no need to perform
runtime unrolling at a later stage.

Note that we already add metadata to disable runtime unrolling to the
scalar loop after vectorization.

The additional unrolling unnecessarily increases code size and compile
time. In addition to that we have several bug reports of unncessary
runtime unrolling for vectorized loops, e.g. PR40961

Compile-time improvements:

  NewPM-O3: -1.04%
  NewPM-ReleaseThinLTO: -0.59%
  NewPM-ReleaseLTO-g: -0.97%

https://llvm-compile-time-tracker.com/compare.php?from=ce1be13a868d0f8afa367975558c1a6175cce33a&to=78bc2e67f22e9e10e61cdb6cdac4bb857d95eb1b&stat=instructions:u

Fixes #40306.

Reviewed By: lebedev.ri, nikic

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

This helps towards the effort to remove UndefValue from LLVM.

Related to https://discourse.llvm.org/t/auto-undef-debug-uses-of-a-deleted-value

Reviewed By: nlopes

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

The differences here are due to SCEVExpander producing GEPs with
explicit offset calculation, a known difference with opaque pointers.

llvm-debuginfod is used by llvm-lit as of
36f01909, so adding this dependency
fixes a "note: Did not find llvm-debuginfod" warning from showing up
when running tests.

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

NFC-ish. There is a functional change but the outputs are semantically
identical. Where we might've before replaced one operand with undef (which
means "this is a kill location marker") the use of `setKillLocation` will
replace all location operands with `undef` (which also means "this is a kill
location marker").

Related to https://discourse.llvm.org/t/auto-undef-debug-uses-of-a-deleted-value

Reviewed By: StephenTozer

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

Additional stream handling functions are added.
These are partially evaluated by StreamChecker, result of the addition is
check for more preconditions and construction of success and failure branches
with specific errno handling.

Reviewed By: Szelethus

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

Reviewed By: pengfei

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

Context https://github.com/llvm/llvm-project/issues/59368

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

These names better reflect the semantics and also the implementation, since
it's not just "undef" operands that are sentinels used to signal that the debug
intrinsic terminates dominating locations definitions.

Related to https://discourse.llvm.org/t/auto-undef-debug-uses-of-a-deleted-value

Reviewed By: StephenTozer

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

The current implementation nicely takes into account when the python interpreter is symlinked (or transitively within a symlinked directory). Sadly, `os.path.islink` returns `false` on Windows if instead of Windows symlinks, junctions are used. This has caused me issues after I started using `scoop` as my package manager on Windows, which creates junctions instead of symlinks.
The fix proposed in this patch is to check whether `realpath` returns a different path to `exe`, and if it does, to simply try again with that path.
The code could also be simplified since `sys.executable` is guaranteed to be absolute, and `os.readlink`, which can return a relative path, is no longer used.

Tested on Windows 11 with Python 3.11 as interpreter and Ubuntu 18.04 with Python 3.6

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

In HLFIR, the address of a Fortran entity in lowering must be defined
by an operation that has the FortranVariableOpInterface (it is a sanity
requirement to ensure that the mlir::Value propagated in certain places
of lowering can be reasoned about).
fir.zero_bits does not have this interface and it makes little sense to
add it since it can "zero initialize" more types than just addresses.

Creating an hlfir.declare for null addresses is a bit too much (what
would be the name), and it would be noisy in the IR.

Instead add a small hlfir.null operation whose codegen is simply a
replacement by fir.zero_bits.

It may also later help dealing with the NULL(MOLD) cases in a nicer
way (the current lowering of this uses special handling it).

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

In function SITargetLowering::performExtractVectorElt,
the output type was not considered which could lead to type mismatches
later.

Reviewed By: arsenm

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

Revert "CodingStandards: restrict CamelCase variable names guideline to llvm/clang/clang-tools-extra/polly/bolt"

This reverts commit ee9ccb11.

See https://reviews.llvm.org/D140585#4019417 and following.
Multiple people requested a revert of this change pending further
discussion.

This reverts commit 2679e8bb.

This change is a significant backwards-compatibility break, which
does in fact break the entire Rust ecosystem, which uses an
-fno-plt -mrelax-relocations=0 default.

Please go through pre-commit review for this change in order to
gain broader consensus.

Previously in collectFrameAllocas, we will iterate every instruction in
the Function and we will iterate the function again later. It is
redundnt.

Fix an edge case `ExprConstant.cpp`'s `EvaluateWithSubstitution` when called by `CheckEnableIf`

The assertion in `CallStackFrame::getTemporary`
could fail during evaluation of nested calls to a function
using `enable_if` when the second argument was a
value-dependent expression.

This caused a temporary to be created for the second
argument with a given version during the
evaluation of the inner call, but we bailed out
when evaluating the second argument of the
outer call due to the expression being value-dependent.
After bailing out, we tried to clean up the argument's value slot but it
caused an assertion to trigger in `getTemporary` as
a temporary for the second argument existed, but only for the inner call and not the outer call.

See the test case for a more complete description of the issue.

Reviewed By: ahatanak

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

RISC-V uses ISD::ABS lower method (abs x) -> (smax_vl x (sub_vl 0, x)) for ISD::VP_ABS.

Reviewed By: craig.topper

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

The result has to be saved to a string as the result might be
overwritten by subsequent calls to getenv.

https://pubs.opengroup.org/onlinepubs/009696899/functions/getenv.html

See the discussion here: https://reviews.llvm.org/D137996#4029305

Reviewed By: pengfei

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

Revert "[Fix]"[-Wunsafe-buffer-usage] Add a new `forEachDescendant` matcher that skips callable declarations""

This reverts commit ef47a0a7.

Revert "[-Wunsafe-buffer-usage] Add a new `forEachDescendant` matcher that skips callable declarations"

This reverts commit b2ac5fd7.

This patch is causing failure in some Sanitizer tests
(https://lab.llvm.org/buildbot/#/builders/5/builds/30522/steps/13/logs/stdio).  Reverting the patch and its' fix.

These new debug values get inserted after the place where the spill
happens, which means they won't be reached by the reverse traversal of
basic block instructions. This would crash or fail assertions if they
contained any virtual registers to be replaced. We can manually handle
the new debug values right away to resolve this.

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

Reviewed By: StephenTozer

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