Require debug build for CodeGen/X86/fsafdo_test2.ll since it checks for
messages only printed in debug mode.

Reviewed By: wenlei, hoy

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

This was probably bugging more than is reasonable, but it makes merging
changes in this file slightly less annoying to have the trailing comma
here. I only noticed this because Rust is currently carrying a patch to
this file and it kept making life a little difficult.

…-it-will-be-removed-from-clang

Android enables zero initialisation globally by default, but also allows
subprojects to override with different option. Clang complains the above
flag being unused in this case.

Instead of adding a 75 char long -no-* flag, don't warn unused argument
for this flag.

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

This allows the instruction selector to realize that it can directly
broadcast the low byte of the memset value, rather than replicating
it to a 64-bit GPR before broadcasting.

This fixes PR50985.

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

Reviewed By: #opaque-pointers, dblaikie

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

…oops

Folding a GEP from outside to inside a loop will materialize an add where there wasn't an equivalent operation before. Check the containing loops before making this fold.

Reviewed By: lebedev.ri

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

In particular we were dropping volatility, which can lead to unwanted
transformations.

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

We still need to tag the llvm.isnan.? intrinsic as vectorizable

__split_buffer_common was entirely unused, and __deque_base_common
was unused except for two calls to __throw_out_of_range(), which have
been inlined.

The usual intent of the __xxx_base_common base classes is to localize
where the exception-throwing code is instantiated, however that wasn't
the case here because we never explicitly instantiated those base classes
in the shared library, unlike what we do for basic_string and vector.

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

This is based on the work done to add strtoll and the other strto
functions. The atoi functions also were added to stdc and
entrypoints.txt.

Reviewed By: sivachandra

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

In 94d0914, I added support for unrolling of multiple exit loops which have multiple exits reaching the latch.  Per reports on the review post commit, I'd missed updating the domtree for one case.  This fix addresses that ommission.

There's no new test as this is covered by existing tests with expensive verification turned on.

…dditional attributes.

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

As reported on https://bugs.llvm.org/show_bug.cgi?id=51020, the
guard widening pass doesn't preserve MemorySSA, so it can no
longer be scheduled in the same loop pass manager as LICM. However,
the loop-schedule.ll test indicates that this is supposed to work.

Fix this by preserving MemorySSA if available, as this seems to be
trivial in this case (we only need to drop the memory access for
the removed guards).

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

Alias analysis is unable to disambiguate accesses to the structure
fields without it unlike distinct variables. As a result we cannot
combine ds_read and ds_write operations in a case of any store in
between which always considered clobbering.

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

This patch extends the runtime unrolling infrastructure to support unrolling a loop with multiple exiting blocks branching to the same exit block used by the latch. It intentionally does not include a cost model change to enable this functionality unless appropriate force flags are used.

This is the prolog companion to D107381. Since this was LGTMed, a problem with DT updating was reported against that patch.  I roled in the analogous fix here as it seemed obvious, and not worth re-review.

As an aside, our prolog form leaves a lot of potential value on the floor when there is an invariant load or invariant condition in the loop being runtime unrolled. We should probably consider a "required prolog" heuristic.  (Alternatively, maybe we should be peeling these cases more aggressively?)

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

This patch handles the return key for compound fields like lists and
mapping fields. The return key, if not handled by the field will select
the next primary element, skipping secondary elements like remove
buttons and the like.

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

…pecify additional attributes."

This reverts commit 95ddc83.

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

With unquoted ${CMAKE_CXX_FLAGS}, the REGEX fails when it's empty:

```CMake Error at lib/scudo/standalone/CMakeLists.txt:14 (string):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
command.```

The default legalization of unsupported vector types is to promote the integers
in each lane, which leads to extra sign or zero extending and masking when
moving data into and out of vectors. Switch our preferred type legalization from
the default to vector widening, which keeps the data in the low lanes of the
vector rather than in the low bits of each lane. The unused high lanes can be
ignored.

Half-wide vectors are now loaded from memory into the low 64 bits of the v128
rather than spread out among the lanes. As a result, v128.load64_splat is a much
more common operation, so add new patterns to support it.

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

Signed-off-by: Dmitry Sidorov <dmitry.sidorov@intel.com>

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@81ebabd

The previous patch has fixed only case with 1-element vectors, however
after closer look at the spec it became clear that
SPV_INTEL_vector_compute actually allows any number of vector elements
(capability VectorAnyINTEL), so this is the proper fix.

This is a follow-up change for b431cc8.

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@e9671a5

CUDA support will be added later in a separate PR.