The LA464 micro-architecture is very sensitive to alignment of hot code,
with performance variation of up to ~12% in the go1 benchmark suite of
the Go language (as observed by me during my work on the Go loong64
port).
[[ https://go.dev/cl/479816 | Manual alignment of certain loops ]] and [[ https://go.dev/cl/479817 | automatic alignment of loop heads ]]
helps a lot there, by reducing much of the random variation and
generally increasing performance, so we naturally want to do the same
here.
Practically, LA464 is the only LoongArch micro-architecture in wide use,
and we are currently supporting just that. The first "4" in "LA464"
stands for "4-issue", in particular its instruction fetch and decode
stages are 4-wide; so functions and branch targets should be preferably
aligned to at least 16 bytes for best throughput.
The Loongson team has benchmarked various combinations of function,
loop, and branch target alignments with GCC.
[[ https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619980.html | The results ]]
show that "16-byte label alignment together with 32-byte function
alignment gives best results in terms of SPEC score". A "label" in GCC
means a branch target; while we don't currently align branch targets,
we do align loops, so in this patch we default to 32-byte function
alignment and 16-byte loop alignment.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D148622
According to the [[ https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html | LoongArch Toolchain Conventions ]]
it is possible to specify the ABI modifier (the "D" part of "LP64D")
via the environment field in the target triple. This is needed for
proper support for Debian-style multiarch tuples as well, so add triple
awareness to `LoongArchSubtarget` via addition of
`LoongArchABI::computeTargetABI`. Let the explicit `--target-abi`
argument intuitively take precedence over the triple-implied ABI.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D142685
There are a few intrinsics or instructions on LoongArch
that are only appropriate for loongarch32 target. So the
feature "32bit" is added to implement it.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D140872
As the LoongArch port is largely modeled after RISCV it has the same
behavior of not accepting `generic` as a CPU name. For better
compatibility with consumers of LLVM (e.g. mesa) follow D121149's suit
and treat `generic` the same as an empty CPU name.
Differential Revision: https://reviews.llvm.org/D134412
This patch introduces basic tablegen infra such as
LoongArch{InstrFormats,InstrInfo,RegisterInfo,CallingConv,}.td.
For now, only add instruction definitions for LoongArch basic integer
operations.
Our initial target is a working MC layer rather than codegen,
so appropriate SelectionDAG patterns will come later.
Differential revision: https://reviews.llvm.org/D115861
