As reported in D93278 post-review symlinking requires privilege escalation on Windows.
Copying is functionally same, so fallback to it for systems that aren't Unix-like.
This is similar to the solution in AddLLVM.cmake.

Reviewed By: ikudrin

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

Refine "Support -march=alderlake"
Compare with tremont, it includes 25 more new features. They are
adx, aes, avx, avx2, avxvnni, bmi, bmi2, cldemote, f16c, fma, hreset, invpcid,
kl, lzcnt, movdir64b, movdiri, pclmulqdq, pconfig, pku, serialize, shstk, vaes,
vpclmulqdq, waitpkg, widekl.

Reviewed By: pengfei

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

This allows to build and test MLIR with `-DLLVM_ENABLE_LIBCXX=ON`.

The check `tightlyNested()` in `LoopInterchange` is similar to the one in `LoopNest`.
In fact, the former misses some cases where loop-interchange is not feasible and results in incorrect behaviour.
Replacing it with the much robust version provided by `LoopNest` reduces code duplications and fixes https://bugs.llvm.org/show_bug.cgi?id=48113.

`LoopInterchange` has a weaker definition of tightly or perfectly nesting-ness than the one implemented in `LoopNest::arePerfectlyNested()`.
Therefore, `tightlyNested()` is instead implemented with `LoopNest::checkLoopsStructure` and additional checks for unsafe instructions.

Reviewed By: Whitney

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

There are two additional cases that were missed in D98131.

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

One commit introduced after the reverted change was using an API
introduced there, this is reintroducing the API, but not the original
broken change.

This spelling matches binutils https://sourceware.org/bugzilla/show_bug.cgi?id=27408

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

This reverts commit 99108c79.
Clang is miscompiling LLVM with this change, a stage-2 build hits
multiple failures.

As a repro, I built clang in a stage1 directory and used it this way:

cmake -G Ninja ../llvm \
  -DCMAKE_CXX_COMPILER=`pwd`/../build-stage1/bin/clang++ \
  -DCMAKE_C_COMPILER=`pwd`/../build-stage1/bin/clang \
  -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU" \
  -DLLVM_ENABLE_PROJECTS=mlir \
  -DLLVM_BUILD_EXAMPLES=ON \
  -DCMAKE_BUILD_TYPE=Release \
  -DLLVM_ENABLE_ASSERTIONS=On
ninja check-mlir

`runtime-multiexit-heuristic.ll`

Added -unroll-runtime-other-exit-predictable=false in
runtime-multiexit-heuristic.ll to make it more robust.
runtime-multiexit-heuristic.ll intention is to test
-unroll-runtime-multi-exit=false, so the default value of
-unroll-runtime-other-exit-predictable should not impact the result.

Reviewed By: Meinersbur

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

predictable. (Add LIT)

Reviewed By: Meinersbur, bmahjour

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

Also clarify a nearby comment regarding block devices.

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

Don't use the mode_t type - the official windows sdk doesn't have that type.
(Mingw headers does have such a typedef though.) The umask function returns
int on windows, in both header variants.

Thus just use auto to deduce the umask return type automatically.

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

Use "expect" instead of "output" for generating "proximate_expected",
pass the arguments to PathEq in the same order as above, rename the
"proximate_expected" variable to be consistent with the naming of the
earlier "expect", use .empty() instead of .native().empty().

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

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

Clarify that the base type endianity is used when creating implicit
location storage.

Remove duplicate definition of the generic type.

Reviewed By: scott.linder

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

I missed this case when adding byref. I believe this is NFC until
pointee types are really removed.

The result of ISD::USUBSAT will never be larger than the LHS. We
can use this to put a bound on the number of leading zeros.

Reviewed By: RKSimon

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

A setcc can be created during LegalizeDAG after select_cc has been
created. This combine will enable us to fold these late setccs.

Reviewed By: luismarques

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

That commit changed SCEVExpander to emit intrinsics instead of icmp+select,
but i forgot about polly, and i'm not sure if any bots complained.

This is a patch that adds folding of two logical and/ors that share one variable:

a && (a && b) -> a && b
a && (a & b)  -> a && b
...

This is towards removing the poison-unsafe select optimization (D93065 has more context).

Reviewed By: nikic

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

[RISCV] Fold (select_cc (xor X, Y), 0, eq/ne, trueV, falseV) -> (select_cc X, Y, eq/ne, trueV, falseV)

This pattern occurs when lowering for overflow operations
introduce an xor after select_cc has already been formed.

I had to rework another combine that looked for select_cc of an xor
with 1. That xor will now get combined away so we just need to
look for the RHS of the select_cc being 1.

Reviewed By: luismarques

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

.. since it will be folded into and/or anyway

This option was originally added to work around a bug in LFTR.
The bug has long since been fixed.

The MemorySSA-based implementation has been enabled without issue
for a while now, so keeping the old implementation around doesn't
seem useful anymore. This drops the MemDep-based implementation.

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

This fixes another unsafe select folding by disabling it if
EnableUnsafeSelectTransform is set to false.

EnableUnsafeSelectTransform's default value is true, hence it won't
affect generated code (unless the flag is explicitly set to false).

This patch makes FoldBranchToCommonDest merge branch conditions into `select i1` rather than `and/or i1` when it is called by SimplifyCFG.
It is known that merging conditions into and/or is poison-unsafe, and this is towards making things *more* correct by removing possible miscompilations.
Currently, InstCombine simply consumes these selects into and/or of i1 (which is also unsafe), so the visible effect would be very small. The unsafe select -> and/or transformation will be removed in the future.
There has been efforts for updating optimizations to support the select form as well, and they are linked to D93065.

The safe transformation is fired when it is called by SimplifyCFG only. This is done by setting the new `PoisonSafe` argument as true.
Another place that calls FoldBranchToCommonDest is LoopSimplify. `PoisonSafe` flag is set to false in this case because enabling it has a nontrivial impact in performance because SCEV is more conservative with select form and InductiveRangeCheckElimination isn't aware of select form of and/or i1.

Reviewed By: nikic

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

Hello all,
I'm trying to fix unsafe propagation of poison values in and/or conditions by using
equivalent select forms (`select i1 A, i1 B, i1 false` and `select i1 A, i1 true, i1 false`)
instead.
D93065 has links to patches for this.

This patch allows unswitch to happen if the condition is in this form as well.
`collectHomogenousInstGraphLoopInvariants` is updated to keep traversal if
Root and the visiting I matches both m_LogicalOr()/m_LogicalAnd().
Other than this, the remaining changes are almost straightforward and simply replaces
Instruction::And/Or check with match(m_LogicalOr()/m_LogicalAnd()).

Reviewed By: nikic

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

for https://reviews.llvm.org/D96945

This is a minor update in directlyImpliesPoison and makes it look into select's
condition.
Splitted from https://reviews.llvm.org/D96945

We can freely shuffle all ones/zeros constants but we can also freely shuffle other constants as long as they only have one use.

Also fix the synopsis in the replace_filename test, while touching
that file.

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

This matches how install(... RUNTIME) is used in e.g. libcxx.

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

This addresses an issue which was revealed by D98022.

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

In "DWARF Extensions For Heterogeneous Debugging" document that the
DWARF generic type has a target architecture defined endianity.

Reviewed By: scott.linder

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

For many directives, the following diagnostics

* `error: unexpected token`
* `error: unexpected token in '.abort' directive"`

are replaced with `error: expected newline`.

`unexpected token` may make the user think a different token is needed.
`expected newline` is clearer about the expected token.

For `in '...' directive`, the directive name is not useful because the next line
replicates the error line which includes the directive.