As discussed in issue #37809, this transform is not safe
if the input is an undefined value.

This is similar to recent changes for urem and sdiv:
d428f09b
99ef341c

There is no difference in codegen on the basic examples,
but this could lead to regressions. We may need to
improve freeze analysis or lowering if that happens.

Presumably, in real cases that are similar to the tests
where a subsequent transform removes the rem, we
will also be able to remove the freeze by seeing that
the parameter has 'noundef'.

We've got a lurking problem with our data flow implementation where different phases disagree, resulting in possible miscompiles. D119518 introduced a workaround, but failed to consider blocks without terminators (e.g. fallthroughs).

I have a deeper rework of the algorithm in flight over in D125232, but this patch is specifically a minimal fix for an active miscompile. That change can be reworked over this once landed.

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

With sufficiently tortured code, it's possible to cause a stack
overflow when parsing declarators. Thus, we now check for resource
exhaustion when recursively parsing declarators so that we can at least
warn the user we're about to crash before we actually crash.

Fixes #51642

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

As a fly-by fix, also let `__cxa_demangle` allocate its buffer alone,
since we are not allowed to pass a non-malloc'd buffer to it.

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

Also fix a sse42 -> sse4.2 typo so that we actually test costs for sse4.2

Also fix a sse42 -> sse4.2 typo so that we actually test costs for sse4.2

 MSVC expects wchar_t to be defined in stddef.h if /Zc:wchar_t- is specified

Reviewed By: efriedma

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

[CSSPGO][llvm-profgen] Do not duplicate context profiles into base profile when converting CS flat profile to nested.

Recent experiments with our two large internal services showed that duplicating context profiles into base profile caused code size inflation and didn't deliver good performance compared to no such duplication. It was a trick we made to catch up with the CS flat profile and I'm now turning it off by default.

The code size inflation mainly comes from the enriched based profiles. A base profile for a function represents the uninlined (or outlined) portion of the whole function running time. Such portion could be very small if a function is inlined into most of its hot callsites. Duplicating context profiles of the function into its base profiles could cause the outlined body to be hot enough and in turn get many of its callees inlined, thus increases the code size. The size inflation could further cause perf regression.

Reviewed By: wenlei

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

If we're promoting an undef I think that means that we expect the
upper bits are zero. undef doesn't guarantee that.

This patch replaces undef with 0 to ensure this. This matches how
a zext or sext of undef would be folded by InstCombine/InstSimplify.

I haven't found a failure from this was just thinking through the code.

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

riscv_fma_vl doesn't have a tail, so use the tail_agnostic policy.

We were already doing this for some patterns. I think the patterns
with fneg and mask were added later and I copied the tail policy
from the unmasked patterns.

Reviewed By: khchen

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

Silence warning with gcc 9.3 about:

[1/351] Building CXX object tools/clang/lib/AST/CMakeFiles/obj.clangAST.dir/MicrosoftCXXABI.cpp.o
../../clang/lib/AST/MicrosoftCXXABI.cpp:57:12: warning: 'virtual unsigned int {anonymous}::MicrosoftNumberingContext::getManglingNumber(const clang::VarDecl*, unsigned int)' was hidden [-Woverloaded-virtual]
   57 |   unsigned getManglingNumber(const VarDecl *VD,
      |            ^~~~~~~~~~~~~~~~~
../../clang/lib/AST/MicrosoftCXXABI.cpp:80:12: warning:   by 'virtual unsigned int {anonymous}::MSHIPNumberingContext::getManglingNumber(const clang::TagDecl*, unsigned int)' [-Woverloaded-virtual]
   80 |   unsigned getManglingNumber(const TagDecl *TD,
      |            ^~~~~~~~~~~~~~~~~

Change-Id: Ia519e77c6454eb020228478dd6498eaf7864dae8

I guess this is an ABI break for the 32 bit AIX configuration, but I'm
not sure if that one is meant to be ABI stable yet or not.

Previously, this used int32_t for this type on linux, but int64_t
on all other platforms. This was added in D68480 /
54fa9ecd, but I don't really see
any discussion around this detail there.

Switching this to 32 bit on 32 bit AIX silences these libcxx build
warnings:

```
In file included from /scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/libcxx/src/atomic.cpp:12:
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1005:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4  bytes) [-Watomic-alignment]
    return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
           ^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:948:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4  bytes) [-Watomic-alignment]
    return __c11_atomic_load(const_cast<__ptr_type>(&__a->__a_value), static_cast<__memory_order_underlying_t>(__order));
           ^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1000:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4  bytes) [-Watomic-alignment]
    return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
           ^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1022:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4  bytes) [-Watomic-alignment]
    return __c11_atomic_fetch_sub(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
           ^
4 warnings generated.
```

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

The re-apply includes fixes to clang tests that were missed in
the original commit.

Original message:
Prior to this patch we would only set to undef the unused arguments of the
external functions. The rationale was that unused arguments of internal
functions wouldn't need to be turned into undef arguments because they
should have been simply eliminated by the time we reach that code.

This is actually not true because there are plenty of cases where we can't
remove unused arguments. For instance, if the internal function is used in
an indirect call, it may not be possible to change the function signature.
Yet, for statically known call-sites we would still like to mark the unused
arguments as undef.

This patch enables the "set undef arguments" optimization on internal
functions when we encounter cases where internal functions cannot be
optimized. I.e., whenever an internal function is marked "live".

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

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

Instead of requiring the client to compute the "isSplat" bit,
compute it internally.  This makes the logic more consistent
and defines away a lot of "elements.size()==1" in the clients.

This addresses Issue #55185

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

too many temporaries.

Fix clang-format errors.

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

This avoids wrapping the line itself awkwardly when it exceeds 80 chars.
It also better matches our style most other places.

This is a re-apply of D123599, which was reverted in 4fe2ab52, now
with a more appropriate assertion. Original commit message follow:

InstrRefBasedLDV can track and describe variable values that are spilt to
the stack -- however it does not current describe the size of the value on
the stack. This can cause uninitialized bytes to be read from the stack if
a small register is spilt for a larger variable, or theoretically on
big-endian machines if a large value on the stack is used for a small
variable.

Fix this by using DW_OP_deref_size to specify the amount of data to load
from the stack, if there's any possibility for ambiguity. There are a few
scenarios where this can be omitted (such as when using DW_OP_piece and a
non-DW_OP_stack_value location), see deref-spills-with-size.mir for an
explicit table of inputs flavours and output expressions.

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

It makes sense to make a non-byval promotion attempt first and then
fall back to the byval one. The non-byval ('usual') promotion is
generally better, for example it does promotion even when a structure
has more elements than 'MaxElements' but not all of them are actually
used in the function.

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

This diff changes the serialization of the `ORIGINAL_PCH_DIR`
entry in module files to be serialized relative to the module's
`BaseDirectory`. This will allow for the module to be relocatable
across machines.

The path is restored relative to the module's BaseDirectory on
deserialization.

Reviewed By: urnathan

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

This diff changes the serialization of the `SUBMODULE_TOPHEADER`
entry in module files to be serialized relative to the module's
`BaseDirectory`. This matches the behavior of the
`SUBMODULE_HEADER` entry and will allow for the module to be
relocatable across machines.

The path is restored relative to the module's `BaseDirectory` on
deserialization.

Reviewed By: urnathan

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

This diff adds a new frontend flag `-fmodule-file-home-is-cwd`.
The behavior of this flag is similar to
`-fmodule-map-file-home-is-cwd` but does not require the module
map files to be modified to have inputs relative to the cwd.
Instead the output modules will have their `BaseDirectory` set
to the cwd and will try and resolve paths relative to that.

The motiviation for this change is to support relocatable pcm
files that are built on different machines with different paths
without having to alter module map files, which is sometimes not
possible as they are provided by 3rd parties.

Reviewed By: urnathan

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

Avoid warning under -fstrict-aliasing by using a call to memcpy to perform type
punning.

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

When a fixed length load is lowered to an SVE masked load, the
result chain is currently set to the input chain of the old load,
rather than the result chain of the new load. This may cause stores
to be incorrectly reordered.

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

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

This PR changes the `SymIntExpr` so the expression that uses a
negative value as `RHS`, for example: `x +/- (-N)`, is modeled as
`x -/+ N` instead.

This avoids producing a very large `RHS` when the symbol is cased to
an unsigned number, and as consequence makes the value more robust in
presence of casts.

Note that this change is not applied if `N` is the lowest negative
value for which negation would not be representable.

Reviewed By: steakhal

Patch By: tomasz-kaminski-sonarsource!

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

Add lowering of the vector.warp_execute_on_lane_0 into scf.if plus memory
transfer for the operands and yield values.

This also add an integration test running on GPU warp. The same tests can be
later re-used with different comment lines to tests distribution
transformations.

This is mostly from @springerm contribution.

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

This adds an extension warning when using the preprocessor conditionals
in a language mode they're not officially supported in, and an opt-in
warning for compatibility with previous standards.

Fixes #55306
Differential Revision: https://reviews.llvm.org/D125178

The underlying map type (DenseMap) has had its resize() function
renamed to reserve() as part of
c04fc7a6 (SVN 264026).

This is only visible when the member function is called, as it is
template type name dependent.

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

These labels aren't needed in the ARM version of WinEH tables, as each
unwind opcode maps to a specific instruction (each opcode is assumed
to represent one instruction), and the written tables don't contain
offsets like on x86_64.

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

operator== and operator!= were added in
1308bb99 / D87369, but this existing
codepath wasn't updated to use them.

Also fix the indentation of the enclosed liens.

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

This lets linalg.dot and friends lower to a complex muladd using ops
from the complex dialect.

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

Reimplement the RemoveBracesLLVM feature which handles a
single-statement block that would get wrapped.

Fixes #53543.

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

Print a debug message when aborting isel (next to the ORE report)
and when folding a load.

TF already carries a patch for this.

Complex nested in other types is perfectly fine, just nested structs
aren't supported. Instead of checking whether there's nesting just check
whether the struct we're dealing with is a complex number.

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

`nvvm_prmt` doesn't seem to be `commutative`. nvvm also sets `IntrSpeculatable` for it.
Here is the doc https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#data-movement-and-conversion-instructions-prmt

Reviewed By: tra, jchlanda

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