Some CPUs do not allow memory accesses to be unaligned, e.g. 2k1000la
who uses the la264 core on which misaligned access will trigger an
exception.
In this patch, a backend feature called `ual` is defined to decribe
whether the CPU supports unaligned memroy accesses. And this feature
can be toggled by clang options `-m[no-]unaligned-access` or the
aliases `-m[no-]strict-align`. When this feature is on,
`allowsMisalignedMemoryAccesses` sets the speed number to 1 and returns
true that allows the codegen to generate unaligned memory access insns.
Clang options `-m[no-]unaligned-access` are moved from `m_arm_Features_Group`
to `m_Group` because now more than one targets use them. And a test
is added to show that they remain unused on a target that does not
support them. In addition, to keep compatible with gcc, a new alias
`-mno-strict-align` is added which is equal to `-munaligned-access`.
The feature name `ual` is consistent with linux kernel [1] and the
output of `lscpu` or `/proc/cpuinfo` [2].
There is an `LLT` variant of `allowsMisalignedMemoryAccesses`, but
seems that curently it is only used in GlobalISel which LoongArch
doesn't support yet. So this variant is not implemented in this patch.
[1]: https://github.com/torvalds/linux/blob/master/arch/loongarch/include/asm/cpu.h#L77
[2]: https://github.com/torvalds/linux/blob/master/arch/loongarch/kernel/proc.c#L75
Reviewed By: xen0n
Differential Revision: https://reviews.llvm.org/D149946
For always poison shifts, any KnownBits return value is valid.
Currently we return unknown, but returning zero is generally more
profitable. We had some code in ValueTracking that tried to do this,
but was actually dead code.
Differential Revision: https://reviews.llvm.org/D150648
This is a follow-up to b71edfaa4ec3c998aadb35255ce2f60bba2940b0
since I forgot the lit.local.cfg files in that one.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: barannikov88, kwk
Differential Revision: https://reviews.llvm.org/D150762
In D79537, `nomerge` was made to only apply to non-tail calls. This fixes it by also applying it to tail calls.
For ARM, I only made the new MI to inherit the flag under `TCRETURNdi` and `TCRETURNri`, because that's the place tail calls got replaced. Not sure if there's any other place needed.
Fixes#61545.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D146749
The placement is currently wrong in the presence of function entry related
instrumentations (prefixdata, -fpatchable-function-entry=, -fsanitize=kcfi,
etc).
This patch splits a restore point to allow it to only post-dominate blocks reachable by use
or def of CSRs(Callee Saved Registers)/FI(Frame Index).
Benchmarking this on SPEC2017, this gives around 4% improvement on povray and no significant change
for others.
Co-authored-by: junbuml
Differential Revision: https://reviews.llvm.org/D42600
Optimize 32-bit 'x+(y<<i)' to (ALSL_W y, x, i) on LoongArch64,
in which 'i' is in [1, 2, 3, 4].
Reviewed By: xen0n, SixWeining
Differential Revision: https://reviews.llvm.org/D147423
Optimize multiplication with some specific immediates to
a pair of `alsl`.
Reviewed By: SixWeining, xen0n
Differential Revision: https://reviews.llvm.org/D147400
Optimize multiplication with some specific immediates to
a pair of `alsl`.
Reviewed By: xen0n, SixWeining
Differential Revision: https://reviews.llvm.org/D147305
It seems the ISA manual's pseudo-code description for the
`BYTEPICK.[WD]` instructions is inaccurate; the behavior described here
should be correct though. The instructions' names are misleading too
(they pick full GRLen-wide words instead of bytes; they just index by
bytes) but let's stick to the official names for now.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D143880
Ideally `addu16i.d` could be paired with `{ld,st}ptr` for faster memory
accesses with 32-bit-aligned offsets (it was designed for this purpose),
but it would require more work and the original use case (GP-relative
accesses) does not exist any more with the current LoongArch psABI.
It could still be used for accelerating additions of certain constants
though, which is what this patch intends to do.
Reviewed By: SixWeining, gonglingqin
Differential Revision: https://reviews.llvm.org/D143710
Normally, the ISD::SELECT is lowered to maskeqz + masknez. This is
inefficient when operands are constants that can be computed easily.
To avoid that, override TargetLowering::convertSelectOfConstantsToMath.
Differential Revision: https://reviews.llvm.org/D143621
There are 12bit offset fields in the ld.[b/h/w/d] and st.[b/h/w/d].
When the constant address is less than 12 bits, the address
calculation is incorporated into the offset field of the instruction.
Differential Revision: https://reviews.llvm.org/D143470
Override hasAndNotCompare() to use more `ANDN` instead of using `AND`
and `NOT`.
This patch enables the following transforms:
(X & Y) == Y ---> (~X & Y) == 0
(X & Y) != Y ---> (~X & Y) != 0.
Differential Revision: https://reviews.llvm.org/D143037
Use the exact addressing mode information instead of the default to
make better use of offsets in instructions.
Differential Revision: https://reviews.llvm.org/D142874
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
We set it conservatively so that it is turned on when optimization
is enabled, i.e. when the optimization level is not `O0`.
Reviewed By: xen0n
Differential Revision: https://reviews.llvm.org/D142876
These are essentially add/sub 1 with a clamping value.
AMDGPU has instructions for these. CUDA/HIP expose these as
atomicInc/atomicDec. Currently we use target intrinsics for these,
but those do no carry the ordering and syncscope. Add these to
atomicrmw so we can carry these and benefit from the regular
legalization processes.
Follow-up for 4ece50737d5385fb80cfa23f5297d1111f8eed39 (D142027).
Assignment Tracking Analysis now always runs and is skipped internally if
assignment tracking is disabled. Update these tests to expect to see the
pass run.
Buildbot failure: https://lab.llvm.org/buildbot/#/builders/57/builds/24094
`-loongarch-numeric-reg` for llvm-mc and llc.
`-M numeric` (which matches GNU objdump) for llvm-objdump and llvm-mc.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D141743
Issue #58168 describes the difficulty diagnosing stack size issues
identified by -Wframe-larger-than. For simple code, its easy to
understand the stack layout and where space is being allocated, but in
more complex programs, where code may be heavily inlined, unrolled, and
have duplicated code paths, it is no longer easy to manually inspect the
source program and understand where stack space can be attributed.
This patch implements a machine function pass that emits remarks with a
textual representation of stack slots, and also outputs any available
debug information to map source variables to those slots.
The new behavior can be used by adding `-Rpass-analysis=stack-frame-layout`
to the compiler invocation. Like other remarks the diagnostic
information can be saved to a file in a machine readable format by
adding -fsave-optimzation-record.
Fixes: #58168
Reviewed By: nickdesaulniers, thegameg
Differential Revision: https://reviews.llvm.org/D135488
I missed that a forward fix was out when reverting
0a652c540556a118bbd9386ed3ab7fd9e60a9754.
This reverts commit 488bea797e167e6bf5ddab5f7eea78031b575ba0.
