Caught with D125604.

Reviewed By: nikic

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

These were left over from when we converted to the update_llc_test_checks script and were just matching some asm/cfi directives - we have CHECK-LABEL to do this properly now.

For generic targets such as SPIR-V clang sets all OpenCL
extensions/features as supported by default. However
concrete targets are unlikely to support all extensions
features, which creates a problem when such generic SPIR-V
binary is compiled for a specific target later on.

To allow compile time diagnostics for unsupported features
this flag is now being exposed in the clang driver.

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

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

Similar to D125988 (and I have a pending follow up patch to handle fpow).

Code beads is useless since the only user, M68k, has moved on to
a new encoding/decoding infrastructure.

This NFC patch is splited from D111617.

Using llvm::ArrayRef rather than llvm::SmallVector, ArrayRef is more generic
interface that could accept both llvm::ArrayRef and llvm::SmallVector.

Reviewed By: reames

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

Most of the folds implemented in this function work fine with
logical operations. We only need to be careful for the cases that
work on non-constant masks, where the RHS operand shouldn't be
poison.

This is a conservative implementation that bails out of illegal
transforms, but we could also change these to insert freeze instead.

This is mostly intended as code cleanup, but it does also add
support for splat vectors to this fold.

(NFC)

Reviewed By: var-const, #libc

Spies: libcxx-commits, mgorny

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

Abseil benchmarks suggest that the conditional checks result in faster code (4-5x)
as they are compiled into conditional move instructions (cmov on x86).

Reviewed By: #libc, philnik, Mordante

Spies: pengfei, Mordante, philnik, libcxx-commits

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

This was probably copy/pasted from the MSCATTER widening.

This fixes incorrect handling of non-moveable types, adding tests for this case.
See [issue 55346](https://github.com/llvm/llvm-project/issues/55346).

The current implementation is based on is_convertible, which is
[defined](https://timsong-cpp.github.io/cppwp/n4659/meta.rel#5) in terms of
validity of the following function:

```
To test() {
  return declval<From>();
}
```

But this doesn't work if To and From are both some non-moveable type, which the
[definition](https://timsong-cpp.github.io/cppwp/n4659/conv#3) of implicit
conversions says should work due to guaranteed copy elision:

```
To to = E;  // E has type From
```

It is this latter definition that is used in the
[definition](https://timsong-cpp.github.io/cppwp/n4659/function.objects#func.require-2)
of INVOKE<R>. Make __invokable_r use __is_core_convertible, which
captures the ability to use guaranteed copy elision, making the
definition correct for non-moveable types.

Fixes llvm/llvm-project#55346.

Reviewed By: #libc, philnik, EricWF

Spies: EricWF, jloser, ldionne, philnik, libcxx-commits

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

The and/or of icmps fold is also applied in reassociated form.
However, this currently only happens for bitwise and of bitwise
and, but not for bitwise and of logical and (or other combinations,
but this is the one being addressed here).

We can do this for bitwise+logical combinations as well, but need
to be a bit careful about which of the resulting ands are logical:
https://alive2.llvm.org/ce/z/WYSjGh
https://alive2.llvm.org/ce/z/guxYnz
https://alive2.llvm.org/ce/z/S5SYxY
https://alive2.llvm.org/ce/z/2rAWeW

Use an and/or of icmp pattern that produces different code
depending on whether it is part of a logical or bitwise and/or.

When the single branch target of a block has been removed try updating
it to target a  block that is kept (by scanning forward in the sequence)
instead of replacing the branch with a return instruction. Doing so
reduces the risk of breaking loop structures meaning that when the loop
is 'interesting' these reductions should have more blocks eliminated.

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

This is a followup to D125754. We introduce two branches, one
before the unrolled loop and one before the epilogue (and similar
for the prologue case). The previous patch only froze the
condition on the first branch.

Rather than independently freezing the second condition, this patch
instead freezes TripCount and bases BECount on it. These are the
two quantities involved in the conditions, and this ensures that
both work on a consistent, non-poisonous trip count.

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

Reviewed By: craig.topper

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

This patch fixes another bug in the RVV frame lowering. While some frame
objects with non-default stack IDs (such scalable-vector alloca
instructions) are considered in the target-independent max alignment
calculations, others (for example, during calling-convention lowering)
are not. This means we'd occasionally align the base of the stack to
only 16 bytes, with no way to ensure that the RVV section contained
within that is aligned to anything higher.

Reviewed By: StephenFan

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

This patch addresses several alignment issues in the stack frame when
RVV objects are taken into account.

One bug is that the RVV stack was never guaranteed to keep the alignment
of the stack *as a whole*. We must maintain a 16-byte aligned stack at
all times, especially when calling other functions. With the standard V
extension, this is conveniently happening since VLEN is at least 128 and
always 16-byte aligned. However, we support Zvl64b which does not
guarantee this. To fix this, the RVV stack size is rounded up to be
aligned to 16 bytes. This in practice generally makes us allocate a
stack sized at least 2*VLEN in size, and a multiple of 2.

    |------------------------------| -- <-- FP
    | 8-byte callee-save           | |      |
    |------------------------------| |      |
    | one VLENB-sized RVV object   | |      |
    |------------------------------| |      |
    | 8-byte local variable        | |      |
    |------------------------------| -- <--...

The previous solution depends on variable name to record the shape
information. However it is not reliable, because in release build
compiler would not set the variable name. It can be accomplished with an
additional option `fno-discard-value-names`, but it is not acceptable
for users.
This patch is to preconfigure the tile register with machine
instruction. It follow the same way what sigle configure does. In the
future we can fall back to multiple configure when single configure
fails due to the shape dependency issue.
The algorithm to configure the tile register is simple in the patch. We
may improve it in the future. It configure tile register based on basic
block. Compiler would spill the tile register if it live out the basic
block. After the configure there should be no spill across tile
confgiure in the register alloction. Just like fast register allocation
the algorithm walk the instruction in reverse order. When the shape
dependency doesn't meet, it insert ldtilecfg after the last instruction
that define the shape.
In post configuration compiler also walk the basic block to collect the
physical tile register number and generate instruction to fill the stack
slot for the correponding shape information.
TODO: There is some following work in D125602. The risk is modifying the
fast RA may cause regression as fast RA is usded for different targets.
We may create an independent RA for tile register.

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

MachineCycle can handle irreducible loop. Natural loop
analysis (MachineLoop) can not return correct loop depth if
the loop is irreducible loop. And MachineSink is sensitive
to the loop depth, see MachineSinking::isProfitableToSinkTo().

This patch tries to use MachineCycle so that we can handle
irreducible loop better.

Reviewed By: sameerds, MatzeB

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

This patch adds basic support for `omp task` to the OpenMPIRBuilder.

The outlined function after code extraction is called from a wrapper function with appropriate arguments. This wrapper function is passed to the runtime calls for task allocation.

This approach is different from the Clang approach - clang directly emits the runtime call to the outlined function. The outlining utility (OutlineInfo) simply outlines the code and generates a function call to the outlined function. After the function has been generated by the outlining utility, there is no easy way to alter the function arguments without meddling with the outlining itself. Hence the wrapper function approach is taken.

Reviewed By: Meinersbur

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

Forward references to ENTRY names to pass them as actual procedure arguments
don't work in all cases, exposing some basic ordering problems in
name resolution for these symbols.  Refactor; create all the
necessary procedure symbols, and either function result or host association
symbols (for subroutines), at the time that the subprogrma scope is
created, so that the names exist in the scope as text "before"
the ENTRY is processed in name resolution.  Some processing
remains in PostEntryStmt() so that we can check that an ENTRY with
an explicit distinct RESULT doesn't also have declarations for the
ENTRY name.

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

This reverts commit a111fb96.

This patch optimizes the transformation of selects to a branch when the heuristics deemed it profitable.
It aggressively sinks eligible instructions to the newly created true/false blocks to prevent their
execution on the common path and interleaves dependence slices to maximize ILP.

Depends on D120232

Reviewed By: davidxl

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

The test specifies a CPU arch but not a particular OS. So if run on
OpenBSD it acts as if it's an OpenBSD/hexagon system. OpenBSD uses
__guard_local instead of __stack_chk_guard so the test will fail. So
specify an OS other than OpenBSD fixes the test.

Reviewed By: MaskRay

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

Exposes interface to free up caching data structure in DWARFDebugLine and DWARFUnit for memory management

This is minimum changes extracted from https://reviews.llvm.org/D78950. The old patch tried to add LRU eviction of caching data structure. Due to multiple layers of interfaces that users could be using, it was not clear where to put the functionality. While we work out on where to put that functionality, it'll be great to add this minimum interface change so that the user could implement their own memory management. More specifically:

* Add a clearLineTable method for DWARFDebugLine which erases the given offset from the LineTableMap.
* DWARFDebugContext adds the clearLineTableForUnit method that leverages clearLineTable to remove the object corresponding to a given compile unit, for memory management purposes. When it is referred to again, the line table object will be repopulated.

Reviewed By: dblaikie

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

Added a separate check for unevaluated statements. Updated InfiniteLoopCheck to use new check

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

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

This is a preparatory patch for the MDNode resize functionality.

Reviewed By: dexonsmith

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

This patch adds the loop-level heuristics for determining whether branches are more profitable than conditional moves.
These heuristics apply to only inner-most loops.

Depends on D120231

Reviewed By: davidxl

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