Reviewed By: MaskRay

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

Revert "[llvm-profdata] Refactoring Sample Profile Reader to increase FDO build speed using MD5 as key to Sample Profile map"

This reverts commit 66ba71d9.

Addressing issues found by:
https://lab.llvm.org/buildbot/#/builders/245/builds/11732
https://lab.llvm.org/buildbot/#/builders/187/builds/12251
https://lab.llvm.org/buildbot/#/builders/186/builds/11099
https://lab.llvm.org/buildbot/#/builders/182/builds/6976

Reviewed By: zixuan-wu

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

Based on https://discourse.llvm.org/t/rfc-what-are-the-blockers-to-turning-on-gvnsink-by-default/72326.

This patch implements a transform op for the FoldArithExtIntoContractionOp
pattern. The pattern folds arith.extf into vector.contract for the
backends with native support for mixed-mode contractions.

Reviewed By: ftynse

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

In a Unicode name was stored in a way that caused
a medial hyphen to be at the end of a a chunk, it would not
be properly ignored by the loose matching algorithm.

For example if `LEFT-TO-RIGHT OVERRIDE` was stored as
`LEFT-` [...], the `-` would not be ignored.

The generators now ensures nodes are not cut accross
medial hyphen boundaries.

Fixes #64161

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

Convert function bodies after all other operations, breaking possible declaration-reference issues between top non-LLVM Ops and non-LLVM ops inside function bodies.

Example:
```
mydialect.global @myglobal : i32
llvm.func @bar(...) {
...
%address = mydialect.global_address @myglobal : llvm.ptr
...
}
```
With the previous scheme `mydialect.global_address` always got translated before `mydialect.global`, this change ensures `mydialect.global` gets translated first.

Reviewed By: mehdi_amini

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

This is a temporary fix (for clang 17) that caps the size of
any array we try to constant evaluate:

    There are 2 limits:
      * We cap to UINT_MAX the size of ant constant evaluated array,
        because the constant evaluator does not support size_t.
      * We cap to `-fconstexpr-steps` elements the size of each individual
        array and dynamic array allocations.
        This works out because the number of constexpr steps already limits
        how many array elements can be initialized, which makes this new
        limit conservatively generous.
        This ensure that the compiler does not crash when attempting to
        constant-fold valid programs.

    If the limit is reached by a given array, constant evaluation will fail,
    and the program will be ill-formed, until a bigger limit is given.
    Or, constant folding will fail and the array will be evaluated at runtime.

    Fixes #63562

Reviewed By: efriedma

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

IdentifierResolver frees resources in the destructor but doesn't
have user-written copy c'tor or assignment operator, so copying it using
default ones can cause double free.

Reviewed By: aaron.ballman

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

CFGStmtMap frees resources in the destructor but doesn't
have user-written copy c'tor or assignment operator, so copying it using
default ones can cause double free.

Reviewed By: cor3ntin

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

DelegatingDeserializationListener frees resources in the destructor but doesn't
have user-written copy c'tor or assignment operator, so copying it using
default ones can cause double free.

Reviewed By: aaron.ballman

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

This is similar to D143540 for import libraries. ARM64EC will need it
for EC symbol table, but it should be fine for other targets as well
and it improves MSVC compatibility. I left mingw case unchanged to be
safe, although I think that it wouldn't hurt to change that as well.

The visible effect in tests is a sorted symbol map.

Revieved By: mstorsjo
Differential Revision: https://reviews.llvm.org/D156473

Reviewed By: jhenderson, efriedma
Differential Revision: https://reviews.llvm.org/D156454

Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D156450

Further preparation for ARM64EC/ARM64X support.

Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D149094

LLVM supports switch ops without case values, for which the optional
caseValues has no value (i.e., std::nullopt, no the empty array).
Handle this case properly when translating MLIR-LLVM to LLVM-IR.

Reviewed By: Dinistro, Mogball

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

This reverts commit bf2ad26b as it
checked in merge conflict markers.

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

Consider FSHR legal if shift amount is constant
Lower FSHL to FSHR if shift amount is constant

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

This reverts commit b6847edf.

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

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

This reverts commit 9cf67592.

Breaking sanitzer buildbots: asan and fast
https://lab.llvm.org/buildbot/#/builders/168/builds/14824
https://lab.llvm.org/buildbot/#/builders/5/builds/35419

Using segmented stacks with execute-only mostly works, but we need to
use the correct movi32 opcode in 6-M, and there's one place where for
thumb1 (i.e. 6-M and 8-M.base) a constant pool was unconditionally
used which needed to be fixed.

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

Implement XCVbi intrinsics for CV32E40P according to the specification.

This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.

Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @PaoloS, @simoncook, @xmj.

Reviewed By: craig.topper

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

Add support for generating and saving the optimization record.
Optimization record lists the optimizations performed by LLVM.

This patch enables the flag in Flang. Clang handles this functionality
using the BackendConsumer which Flang doesn't have, hence, was
implemented in CodeGenAction::executeAction

FlangOption added to all variants of fsave-optimization-record in
clang/include/clang/Driver/Options.td . Clang handles it the
same way.

opt_record_file, opt_record_passes and opt_record_format flags
in Options.td were moved out of the group [CC1Option, NoDriverOption]
to allow flang -fc1 support.

The renderRemarksOptions and willEmitRemarks functions in
clang/lib/Driver/ToolChains/Flang.cpp follow same syntax as clang.
In flang/lib/Frontend/CompilerInvocation.cpp we update the field
OptRecordFile with the provided optimization file value. Clang
doesn't do this as it processes the Options.td, mapping the
OptRecordFile earlier on.

Reviewed By: awarzynski, tblah

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

This breaks ppc64le builders:
https://lab.llvm.org/buildbot/#builders/230/builds/16405

Mapping symbols [1] are special ELF symbols that can be inserted to
indicate regions of code or data. A sequence of data bytes is indicated
by a `$d` (or `$d.<any>`) symbol pointing to its start while a sequence
of instructions uses a `$x` (or `$x.<any>`) symbol. This can be used,
for example, to assist disassembling a memory region containing both
data and code.

This patch implements mapping symbols for RISC-V, copying the
implementation mostly from the AArch64 target.

Note that the `$x<ISA>` mapping symbol, indicating an instruction
sequence with a specific ISA extension, is not implemented by this
patch. As far as I can tell, binutils doesn't implement this yet either.

Note that this patch uses the same symbol naming convention as the
AArch64 target: always use `$x.i` and `$d.i` (where `i` is a
monotonically increasing counter). This differs from binutils where all
symbols are named `$x` or `$d` (causing multiple symbol having the same
name). I'm not not sure whether it makes more sense to avoid duplicate
symbol names or be consistent with binutils.

Note that the handling of nop-slides inserted for alignment differs from
binutils: binutils always marks the nops as instructions (`$x`) while
this patch doesn't insert a symbol for the nops (so the last inserted
symbol is used). I believe binutil's behavior makes most sense but this
seems difficult to implement in LLVM as the insertion of nops is handled
by `RISCVAsmBackend`. At this point, inserting ELF symbols seems
impossible. Any ideas for how to handle this would be appreciated.

[1]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#mapping-symbol

Depends on D156190 and D156236

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

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

D108961 introduced relaxation for out-of-range conditional branches.
However, relaxation was only performed when the branch target could be
resolved. I believe this has two undesired consequences:

- `b<cc> ... foo`, where `foo` is undefined, would not be relaxed
  although there is no guarantee the offset to `foo` will fit;
- Conditional branches are never relaxed with `-mattr=+relax` because MC
  considers fixups where `shouldForceRelocation` returns true (which
  will be the case with `+relax`) to be unresolved.

Note that binutils performs conditional branch relaxation in both cases.

This patch proposes to perform conditional branch relaxation even when
the target cannot be resolved.

Note on llvm/test/MC/RISCV/long-conditional-jump.s: I've removed the
`.p2align` because this causes alignment nops to be inserted for the
`+relax` tests. This in turn causes all the branch targets to change
compared to the non-`+relax` tests. Since `+relax` shouldn't change
these offsets, I found this confusing and hence chose to remove the
alignment.

Reviewed By: asb, MaskRay, reames

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

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

Implement XCVsimd intrinsics for CV32E40P according to the specification.

This commit is part of a patch-set to upstream the 7 vendor specific extensions of CV32E40P.

Contributors: @CharKeaney, @jeremybennett, @lewis-revill, @liaolucy, Nandni Jamnadas, @PaoloS, @simoncook, @xmj.

Reviewed By: craig.topper

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

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

D154958 enables branch relaxation for unresolved symbols. This has an
interesting consequence for some LLD tests: branch relocations are
tested by using branches to undefined symbols and defining them, with
different values, on the LLD command line. These tests broke and there
doesn't seem to be an easy workaround: as far as I can tell, there is no
way to convince llvm-mc to emit a branch relocation to an undefined
symbol without branch relaxation kicking in.

This patch proposes to add a flag, `-riscv-asm-relax-branches=0`, to do
just that. The main purpose for this flag is for testing but it might be
seen as a first step to some kind of "strict" or WYSIWYG mode (i.e.,
what you give to the assembler is exactly what comes out). The need for
this has been mentioned in, for example, D108961. However, I suspect
there will be a lot of discussion around what exactly such a strict mode
would look like. Therefore, I gated this feature behind a CLI flag
instead of adding a new target feature.

Reviewed By: asb, MaskRay

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

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