| commit | ededcb004117eb60d9a2316ae6a8db660e7006a1 | [log] [tgz] |
|---|---|---|
| author | Momchil Velikov <[email protected]> | Thu Sep 21 17:07:16 2023 |
| committer | Momchil Velikov <[email protected]> | Thu Sep 21 17:30:01 2023 |
| tree | 8eab8df28db5a6b56a17d78971cf3ff238e8e52d | |
| parent | b4301df61fc77a9d54ac236bc88742a731285f1c [diff] |
[AArch64] Refactor AArch64InstrInfo::isAsCheapAsAMove (NFC)
- remove `FeatureCustomCheapAsMoveHandling`: when you have target
features affecting `isAsCheapAsAMove` that can be given on command
line or passed via attributes, then every sub-target effectively has
custom handling
- remove special handling of `FMOVD0`/etc: `FVMOV` with an immediate
zero operand is never[1] more expensive tha an `FMOV` with a
register operand.
- remove special handling of `COPY` - copy is trivially as cheap as
itself
- make the function default to the `MachineInstr` attribute
`isAsCheapAsAMove`
- remove special handling of `ANDWrr`/etc and of `ANDWri`/etc: the
fallback `MachineInstr` attribute is already non-zero.
- remove special handling of `ADDWri`/`SUBWri`/`ADDXri`/`SUBXri` -
there are always[1] one cycle latency with maximum (for the
micro-architecture) throughput
- check if `MOVi32Imm`/`MOVi64Imm` can be expanded into a "cheap"
sequence of instructions
There is a little twist with determining whether a
MOVi32Imm`/`MOVi64Imm` is "as-cheap-as-a-move". Even if one of these
pseudo-instructions needs to be expanded to more than one MOVZ,
MOVN, or MOVK instructions, materialisation may be preferrable to
allocating a register to hold the constant. For the moment a cutoff
at two instructions seems like a reasonable compromise.
[1] according to 19 software optimisation manuals
Reviewed By: dmgreen
Differential Revision: https://reviews.llvm.org/D154722
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Join the LLVM Discourse forums, Discord chat, or #llvm IRC channel on OFTC.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.