Added some comments (particularly around finalize() and
finalizeContents()) as well as doing some rephrasing / grammar fixes for
existing comments.

Also did some minor style fixups, such as by putting methods together in
a class definition and having fields of similar types next to each
other.

Reviewed By: #lld-macho, oontvoo

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

Generalize D99629 for ELF. A default visibility non-local symbol is preemptible
in a -shared link. `isInterposable` is an insufficient condition.

Moreover, a non-preemptible alias may be referenced in a sub constant expression
which intends to lower to a PC-relative relocation. Replacing the alias with a
preemptible aliasee may introduce a linker error.

Respect dso_preemptable and suppress optimization to fix the abose issues. With
the change, `alias = 345` will not be rewritten to use aliasee in a `-fpic`
compile.
```
int aliasee;
extern int alias __attribute__((alias("aliasee"), visibility("hidden")));
void foo() { alias = 345; } // intended to access the local copy
```

While here, refine the condition for the alias as well.

For some binary formats like COFF, `isInterposable` is a sufficient condition.
But I think canonicalization for the changed case has little advantage, so I
don't bother to add the `Triple(M.getTargetTriple()).isOSBinFormatELF()` or
`getPICLevel/getPIELevel` complexity.

For instrumentations, it's recommended not to create aliases that refer to
globals that have a weak linkage or is preemptible. However, the following is
supported and the IR needs to handle such cases.
```
int aliasee __attribute__((weak));
extern int alias __attribute__((alias("aliasee")));
```

There are other places where GlobalAlias isInterposable usage may need to be
fixed.

Reviewed By: rnk

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

Reviewed By: gysit

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

If you don't include a target that directly references CFGuard it
doesn't get built into opt or the llvm library build, which causes some
test cases to fail.

Including this in opt explicitly resolve those issues.

See the updated insert-before.test for the effects: many synthetic
sections are SHF_ALLOC|SHF_WRITE. If they are discarded, we don't want
to propagate their flags to subsequent output section descriptions.

`getFirstInputSection(sec) == nullptr` can technically be merged into
`isDiscardable` but I'd like to postpone that as not sharing code may give more
refactoring opportunity.

Depends on D118529.

Reviewed By: peter.smith, bluca

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

adjustSectionsBeforeSorting updates some output section attributes
(alignment/flags) and removes discardable empty sections. When it is called,
INSERT commands have not been processed. Therefore the flags propagation rule
may not affect output sections defined in an INSERT command properly.

Fix this by moving processInsertCommands before adjustSectionsBeforeSorting.

adjustSectionsBeforeSorting is somewhat misnamed. The order between it and
sortInputSections does not matter. With the pass shuffle, the name of
adjustSectionsBeforeSorting becomes wrong. Therefore rename it. The new
name is not set into stone. The function mixes several tasks and the
code may be refactored in a way that we may give them more meaningful
names.

With this patch, I think the behavior of attribute propagation becomes more
reasonable. In particular, in the absence of non-INSERT SECTIONS,
inserting a section after a SHF_ALLOC one will give us a SHF_ALLOC section,
not a non-SHF_ALLOC one (see linkerscript/insert-after.test).

Reviewed By: peter.smith, bluca

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

The deduplication requires a DenseMap of the same size of the local part of
.strtab . I optimized it in e2054454 but it is
still quite slow.

For Release build of clang, deduplication makes .strtab 1.1% smaller and makes the link 3% slower.
For chrome, deduplication makes .strtab 0.1% smaller and makes the link 6% slower.

I suggest that we only perform the optimization with -O2 (default is -O1).
Not deduplicating local symbol names will simplify parallel symbol table write.

Reviewed By: peter.smith

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

In binutils, ar -s and randlib don't convert a thin archive to a regular one.
This behavior makes sense and this patch ports the behavior.

Reviewed By: gbreynoo

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

In GNU ar (since 2008), the modifier 'T' means creating a thin archive.
In many other ar implementations (FreeBSD, macOS, elfutils, etc), -T
means "allow filename truncation of extracted files", as specified by
X/Open System Interface.

For portability, 'T' with thin archive semantics should be avoided.

See https://sourceware.org/bugzilla/show_bug.cgi?id=28759 binutils 2.38
will deprecate 'T' (without diagnostic) and add --thin.

Reviewed By: jhenderson

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

Added support for alternate ops vectorization of the cmp instructions.
It allows to vectorize either cmp instructions with same/swapped
predicate but different (swapped) operands kinds or cmp instructions
with different predicates and compatible operands kinds.

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

This fixes https://github.com/llvm/llvm-project/issues/52636.

This patch adds partial lowering of the "EXIT" intrinsic to
the backend runtime hook implemented in patch D110741. It also adds a
helper function to the `RuntimeCallTestBase.h` for testing for an
intrinsic function call in a `mlir::Block`.

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

Replace `f<ELFT>(x)` with `InvokeELFT(f, x)`.
The size reduction comes from turning `link` from 4 specializations into 1.

My x86-64 lld executable is 26KiB smaller.

Reviewed By: ikudrin

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

Make the check for a complete SchedModel work as expected: report any
supported instruction not having scheduler info.

For unclear reasons there was a variable 'HadCompleteModel' that caused
e.g. new instructions for a new subtarget not to be reported. This variable
is now simply removed as all in-tree targets seem to build fine without it.

Review: Simon Pilgrim

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

with same/swapped predicate.

This reverts commit 25bf6a2a.

With this patch there should be no more namespaces without closing comment

Reviewed By: ldionne, Quuxplusone, #libc

Spies: libcxx-commits

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

As per Steve Scalpone's suggestion, I've renamed the runtime routine to
better evoke its purpose.

I implemented a routine called "Crash" and added a test.

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

These tests emit unexpected diagnostics on AIX because the byval alignment warning is emitted too aggressively. https://reviews.llvm.org/D118350 is supposed to provide a proper fix to the problem, but for the time being disable the tests to unblock.

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

When attempting to cast a pybind11 handle to an MLIR C API object through
capsules, the binding code would attempt to directly access the "_CAPIPtr"
attribute on the object, leading to a rather obscure AttributeError when the
attribute was missing, e.g., on non-MLIR types. Check for its presence and
throw a TypeError instead.

Depends On D117646

Reviewed By: stellaraccident

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

DWARF64 was implemented at version 3, so if a DWARF version less than 3 is specified, DWARF64 does not get selected. Since XCOFF64 requires DWARF64, the modified tests fail on 64-bit AIX. This patch bumps these tests to dwarf version 3 to maintain test coverage on 64-bit AIX.

Reviewed By: dblaikie

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

We tracked down some non-determinism in compilation output to the
DFAJumpThreading pass. These changes fixed our issue:

* Make the DefMap type a MapVector to make its iteration order depend on
  insertion order.
* Sort the values to be inserted into NewDefs by instruction order to
  make the insertion order deterministic. Since these values come from
  iterating over a ValueMap, which doesn't have deterministic iteration
  order, I couldn't fix this at its source.

Reviewed By: alexey.zhikhar

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

This is leftover from the advisor refactoring. Straight-forward copy and
paste.

The first phase of the analysis can avoid a vsetvli if an earlier
instruction in the block used an SEW and LMUL that when combined with
the EEW of the load/store would produce the desired EMUL. If we
avoided a vsetvli this will affect the global analysis we do in the
second phase.

The third phase where we really insert the vsetvlis needs to agree
with the first phase. If it doesn't we can insert vsetvlis that
invalidate the global analysis.

In the test case there is a VSETVLI in the preheader that sets
SEW=64 and LMUL=1. Inside the loop there is a VADD with SEW=64 and LMUL=1.
This VADD is followed by a store that wants wants SEW=32 LMUL=1/2.
Because it has EEW=32 as part of the opcode the SEW=64 LMUL=1 from the
VADD can be become EMUL=1 for the store. So the first phase determines no
vsetvli is needed.

The third phase manages CurInfo differently than BBInfo.Change from the
first phase. CurInfo is only updated when we see a vsetvli or insert
a vsetvli. This was done to allow predecessor block information from
the global analysis to be applied to multiple instructions. Since the
loop body has no vsetvli we won't update CurInfo for either the VADD
or the VSE. This prevented us from checking the store vsetvli elision
for the VSE resulting in a vsetvli SEW=32 LMUL=1/2 being emitted which
invalidated the global analysis.

To mitigate this, I've added a BBLocalInfo variable that more closely
matches the first phase propagation. This gets updated based on the
VADD and prevents emitting a vsetvli for the store like we did in the
first phase.

I wonder if we should do an earlier phase to handle the load/store case
by adding more pseudo opcodes and changing the SEW/LMUL for those
instructions before the insertion analysis. That might be more robust
than trying to guarantee two phases make the same decision.

Fixes the test from D118629.

Reviewed By: frasercrmck

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

Make specializations of `DataflowAnalysis` extendable with domain-specific
logic for comparing distinct values when comparing environments.

This includes a breaking change to the `runDataflowAnalysis` interface
as the return type is now `llvm::Expected<...>`.

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.

Reviewed-by: ymandel, xazax.hun

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

This should not be an error. V is a valid implementation of Zve.

Spec clarified here
https://github.com/riscv/riscv-v-spec/commit/9a877e8553362ff03a9b22b98e321b59aff50398

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

In a similar vein to 236fbf57,
make sure we don't early-exit before the dead constant check.

This seems to be the root cause of hangs on amdgpu. Reverting while investigating.
This reverts commit 7b9844cc.

Summary:
This patch removes some of the check lines that are problematic on
MACOS. The output on the MAC systems works but should be slightly
different. Because this is simply the output being slightly different
rather than broken functionality the test is being changed.

Constant expressions with a non-pointer result type used an early
exit that bypassed the later dead constant user check, and resulted
in different optimization outcomes depending on whether dead users
were present or not.

This fixes the issue reported in https://reviews.llvm.org/D117223#3287039.

[PowerPC] Update P10 vector insert patterns to use refactored load/stores, and update handling of v4f32 vector insert.

This patch updates the P10 patterns with a load feeding into an insertelt to
utilize the refactored load and store infrastructure, as well as updating any
tests that exhibit any codegen changes.

Furthermore, custom legalization is added for v4f32 on Power9 and above to not
only assist with adjusting the refactored load/stores for P10 vector insert,
but also it enables the utilization of direct moves.

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