The alternative outputs of std::put_time and std::strftime are the
easiest to test with the Japanese locale. This is a preparation for the
tests of the chrono formatters.

Note since it takes a while before the Docker file changes propagate to
the build nodes the verification of the locale is done in a separate
patch.

Reviewed By: ldionne, #libc

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

Reduced the details of the non-chrono formatting information. This has
been shipped and these details part of P0645 which is still documented.
Removing this information keeps the information up-to-date.

Adds the formatters required for the types chrono namespace.

Reviewed By: ldionne, #libc

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

This change fixes an assert that occurs in the SMT layer when refuting a
finding that uses pointers of two different sizes. This was found in a
downstream build that supports two different pointer sizes, The CString
Checker was attempting to compute an overlap for the 'to' and 'from'
pointers, where the pointers were of different sizes.

In the downstream case where this was found, a specialized memcpy
routine patterned after memcpy_special is used. The analyzer core hits
on this builtin because it matches the 'memcpy' portion of that builtin.
This cannot be duplicated in the upstream test since there are no
specialized builtins that match that pattern, but the case does
reproduce in the accompanying LIT test case. The amdgcn target was used
for this reproducer. See the documentation for AMDGPU address spaces here
https://llvm.org/docs/AMDGPUUsage.html#address-spaces.

The assert seen is:

`*Solver->getSort(LHS) == *Solver->getSort(RHS) && "AST's must have the same sort!"'

Ack to steakhal for reviewing the fix, and creating the test case.

Reviewed By: steakhal

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

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

VectorizerStart extension is module callback in old PM, but is function
callback in new PM. We lack a module extension point between end of
buildModuleSimplificationPipeline and the function optimization
(including vectorizer) pipeline. So this patch adds a new module
extension point before the function optimization pipeline.

Reviewed By: aeubanks

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

This patch fixes a bug in LinearTransform::applyTo where it did not carry the
IdKind information, and instead treated every id as IdKind::Domain.

Reviewed By: arjunp

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

Previously, if a `#pragma clang assume_nonnull begin` was at the
end of a premable with a `#pragma clang assume_nonnull end` at the
end of the main file, clang would diagnose an unterminated begin in
the preamble and an unbalanced end in the main file.

With this change, those errors no longer occur and the case above is
now properly handled. I've added a corresponding test to clangd,
which makes use of preambles, in order to verify this works as
expected.

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

Summary:
  To compute the size of a VALU/SALU instruction, we need to check whether an operand
could ever be literal. Previously isLiteralConstant was used, which missed cases
like global variables or external symbols. These misses lead to under-estimation of
the instruction size and branch offset, and thus incorrectly skip the necessary branch
relaxation when the branch offset is actually greater than what the branch bits can hold.
In this work, we use isLiteralConstantLike to check the operands. It maybe conservative,
but it is safe.

Reviewers: arsenm

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

dd917342 (Add clear_cache implementation for ppc64. Fix buffer to
meet ppc64 alignment., 2017-07-28), adds an implementation for
__builtin___clear_cache on powerpc64, which was promptly ammended to
also be used with big endian mode in f67036b6 (This ppc64 implementation
of clear_cache works for both big and little endian., 2017-08-02)

clang will use this implementation for it's builtin on FreeBSD and result
in an abort() in the cases where 32-bit generation was requested (ex in
macppc or when the big endian powerpc64 build was done with "-m32") and as
reported[1] recently with pcre2, but there is no reason why the same code
couldn't be used in those cases, so use instead the more generic identifier
for the PowerPC architecture.

While at it, update the comment to reflect that POWER8/9 have a 128 byte
wide cache line and so the code could instead use 64 byte windows instead
but that possible optimization has been punted for now.

[1] https://github.com/PhilipHazel/pcre2/issues/92

Reviewed By: jhibbits, #powerpc, MaskRay

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

This was truncating inequalities instead of equalities.

Reviewed By: Groverkss

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

Instead of first creating a lambda for calculating the range,
then collecting the ranges for the operands, and then calling the
lambda on those ranges, we can first calculate the operand ranges
and then calculate the result directly in the switch.

This avoids the awkward "Abort" flag, because we can simply
early-return instead.

[MLIR][Presburger] MultiAffineFunction:eliminateRedundantLocalId: fix bug where local offset was not considered

Previously, when updating the outputs matrix, the local offset was not being considered.

Reviewed By: Groverkss

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

This reverts the revert commit 2760cdc9.

This version pulls in the code to create the vector loop object in VPlan
from D121624.

This is needed because otherwise existing LoopInfo verification will
fail, as a loop block doesn't have in-loop successors now that we
do not replace the branch.

Now that we do not add new loops during skeleton construction, there's
also no need to verify LI there.

It seems to have been added back in 761e42fa for Clang to use it,
however it seems to have never been used for that purpose, so it is
probably fine to remove it.

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

Revert "[llvm-readobj][MachO] Add option to sort the symbol table before dumping (MachO only, for now)."

This reverts commit ea9cf2dc.

Broke LLDB - reverting to investigage

For some reason, we've been going without a MSAN CI job, even though
even run-buildbot defined a generic-msan job. This must have been an
oversight that went unnoticed. Thanks to @EricWF for the catch.

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

This patch adds limited modeling of the `value_or` method. Specifically, when
used in a particular idiom in a comparison to implicitly check whether the
optional holds a value.

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

This inverts a fold recently added to IR with:
3491f2f4

We can put -bidirectional on the Alive2 examples to show that
the reverse transforms work:
https://alive2.llvm.org/ce/z/8iVQwB

The motivation for the IR change was to improve matching to
'fabs' in IR (see https://github.com/llvm/llvm-project/issues/38828 ),
but it regressed x86 codegen for 'not-quite-fabs' patterns like
(X > -X) ? X : -X.
Ie, when there is no fast-math (nsz), the cmp+select is not a proper
fabs operation, but it does map nicely to the unusual NAN semantics
of MINSS/MAXSS.

I drafted this as a target-independent fold, but it doesn't appear to
help any other targets and seems to cause regressions for SystemZ at
least.

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

This would help making tests less brittle as the order will be fixed.

(see also PR/53026)

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

Unfortunately this just shows that the test case for D47740 never
really tested what it was supposed to test.

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

Reviewed By: ftynse

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

According to the current design, if a floating point operation is
represented by a constrained intrinsic somewhere in a function, all
floating point operations in the function must be represented by
constrained intrinsics. It imposes additional requirements to inlining
mechanism. If non-strictfp function is inlined into strictfp function,
all ordinary FP operations must be replaced with their constrained
counterparts.

Inlining strictfp function into non-strictfp is not implemented as it
would require replacement of all FP operations in the host function,
which now is undesirable due to expected performance loss.

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

This fixes a TODO in constantArgPropagation() to make it feature complete.
However, I do find myself in agreement with the review comments in
https://reviews.llvm.org/D106426. I don't think we should pursue
specializing such recursive functions as the code size increase becomes
linear to 'max-iters'. Compiling the modified test just with -O3 (no
function specialization) generates the same code.

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

Fixed whitespace and punctuation issues, added a name to a link, and
fixed a typo.

This reverts commit 32bc83d1.

This is causing bots with expensive-checks to fail. Revert while I
investigate.

The AMX combiner would store undef or zero to stack and invoke tileload
to load the data to tile register. To avoid the store/load, we can
materialzie undef or zero value to tilezero.

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

Reviewed By: sammccall

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

The only remaining use was to get the exit block of the loop. Instead of
relying on the loop, use the successor of VectorHeaderBB
(LoopMiddleBlock) directly to set VPTransformState::CFG::ExitB

Depends on D121621.

Reviewed By: Ayal

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

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

While not strictly required after PEP-420, it is better to have one, since not
all tooling supports implicit namespace packages.

Reviewed By: ftynse

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

This commit fixes or disables all errors reported by

    python3 -m mypy -p mlir --show-error-codes

Note that unhashable types cannot be currently expressed in a way compatible
with typeshed. See https://github.com/python/typeshed/issues/6243 for details.

Reviewed By: ftynse

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