Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2 |
|
#
52e5683d |
| 14-Oct-2024 |
Serge Pavlov <sepavloff@gmail.com> |
[GlobalISel][ARM] Legalization of G_CONSTANT using constant pool (#98308)
ARM uses complex encoding of immediate values using small number of
bits. As a result, some values cannot be represented as
[GlobalISel][ARM] Legalization of G_CONSTANT using constant pool (#98308)
ARM uses complex encoding of immediate values using small number of
bits. As a result, some values cannot be represented as immediate
operands, they need to be synthesized in a register. This change
implements legalization of such constants with loading values from
constant pool.
---------
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
show more ...
|
Revision tags: llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1 |
|
#
a79db96e |
| 25-Jul-2024 |
Kai Nacke <kai.peter.nacke@ibm.com> |
[GISel][TableGen] Generate getRegBankFromRegClass (#99896)
Generating the mapping from a register class to a register bank is complex: - there can be lots of register classes - the mapping may be
[GISel][TableGen] Generate getRegBankFromRegClass (#99896)
Generating the mapping from a register class to a register bank is complex: - there can be lots of register classes - the mapping may be ambiguos - a register class can span several register banks (e.g. a register class containing all registers) - the type information is not enough to decide which register bank to map to (e.g. a register class containing floating point and vector registers, and all register can represent a f64 value)
The approach taken here is to encode the register banks in an array indexed by the ID of the register class. To save space, the entries are packed into chunks of size 2^n.
show more ...
|
Revision tags: llvmorg-20-init |
|
#
4c9b71dd |
| 26-Jun-2024 |
Serge Pavlov <sepavloff@gmail.com> |
[GlobalISel][ARM] Legalze set_fpmode and get_fpmode (#96467)
Implement handling of get/set floating point control modes for ARM in
Global Instruction Selector.
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5 |
|
#
c12bc57e |
| 30-Apr-2024 |
Eleanor Bonnici <eleanor.bonnici@arm.com> |
Do not use R12 for indirect tail calls with PACBTI (#82661)
When compiling for thumbv8.1m with +pacbti and making an indirect tail
call, the compiler was free to put the function pointer into R12.
Do not use R12 for indirect tail calls with PACBTI (#82661)
When compiling for thumbv8.1m with +pacbti and making an indirect tail
call, the compiler was free to put the function pointer into R12.
This is incorrect because R12 is restored to contain authentication code
for the caller's return address.
This patch excludes R12 from the set of registers the compiler can put
the function pointer in.
Fixes https://github.com/llvm/llvm-project/issues/75998
show more ...
|
Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2 |
|
#
b4eb7a10 |
| 04-Feb-2024 |
Serge Pavlov <sepavloff@gmail.com> |
[GlobalISel][ARM] Legalze set_fpenv and get_fpenv (#79852)
Implement handling of get/set floating point environment for ARM in
Global Instruction Selector. Lowering of these intrinsics to operation
[GlobalISel][ARM] Legalze set_fpenv and get_fpenv (#79852)
Implement handling of get/set floating point environment for ARM in
Global Instruction Selector. Lowering of these intrinsics to operations
on FPSCR was previously inplemented in DAG selector, in GlobalISel it is
reused.
show more ...
|
Revision tags: llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5 |
|
#
c4821073 |
| 10-Nov-2023 |
Craig Topper <craig.topper@sifive.com> |
[GISel] Make target's PartMapping, ValueMapping, and BankIDToCopyMapIdx arrays const. (#71079)
AMDGPU arrays were already const.
|
Revision tags: llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6 |
|
#
aa7eace8 |
| 03-Jun-2023 |
Nitin John Raj <nitin.raj@sifive.com> |
[TableGen][GlobalISel] Account for HwMode in RegisterBank register sizes
This patch adds logic for determining RegisterBank size to RegisterBankInfo, which allows accounting for the HwMode of the ta
[TableGen][GlobalISel] Account for HwMode in RegisterBank register sizes
This patch adds logic for determining RegisterBank size to RegisterBankInfo, which allows accounting for the HwMode of the target. Individual RegisterBanks cannot be constructed with HwMode information as construction is generated by TableGen, but a RegisterBankInfo subclass can provide the HwMode as a constructor argument. The HwMode is used to select the appropriate RegisterBank size from an array relating sizes to RegisterBanks.
Targets simply need to provide the HwMode argument to the <target>GenRegisterBankInfo constructor. The RISC-V RegisterBankInfo constructor has been updated accordingly (plus an unused argument removed).
Reviewed By: simoncook, craig.topper
Differential Revision: https://reviews.llvm.org/D76007
show more ...
|
Revision tags: llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
#
62128719 |
| 28-Mar-2022 |
Kazu Hirata <kazu@google.com> |
[Target] Apply clang-tidy fixes for readability-redundant-member-init (NFC)
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
#
cb216076 |
| 15-Feb-2022 |
Mircea Trofin <mtrofin@google.com> |
[nfc][codegen] Move RegisterBank[Info].h under CodeGen
This wraps up from D119053. The 2 headers are moved as described, fixed file headers and include guards, updated all files where the old paths
[nfc][codegen] Move RegisterBank[Info].h under CodeGen
This wraps up from D119053. The 2 headers are moved as described, fixed file headers and include guards, updated all files where the old paths were detected (simple grep through the repo), and `clang-format`-ed it all.
Differential Revision: https://reviews.llvm.org/D119876
show more ...
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
e5947760 |
| 03-Jan-2022 |
Kazu Hirata <kazu@google.com> |
Revert "[llvm] Remove redundant member initialization (NFC)"
This reverts commit fd4808887ee47f3ec8a030e9211169ef4fb094c3.
This patch causes gcc to issue a lot of warnings like:
warning: base cl
Revert "[llvm] Remove redundant member initialization (NFC)"
This reverts commit fd4808887ee47f3ec8a030e9211169ef4fb094c3.
This patch causes gcc to issue a lot of warnings like:
warning: base class ‘class llvm::MCParsedAsmOperand’ should be explicitly initialized in the copy constructor [-Wextra]
show more ...
|
#
fd480888 |
| 02-Jan-2022 |
Kazu Hirata <kazu@google.com> |
[llvm] Remove redundant member initialization (NFC)
Identified with readability-redundant-member-init.
|
Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
#
df8ed392 |
| 26-Nov-2020 |
Kristof Beyls <kristof.beyls@arm.com> |
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls.
As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls.
As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used.
This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled.
Differential Revision: https://reviews.llvm.org/D92469
show more ...
|
Revision tags: llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2 |
|
#
ae391054 |
| 07-Feb-2020 |
Huihui Zhang <huihuiz@quicinc.com> |
Reland "[ARM] Fix data race on RegisterBank initialization."
Update lambda function static auto InitializeRegisterBankOnce = [this](const auto &TRI) { with static auto InitializeRegisterBankOnce = [
Reland "[ARM] Fix data race on RegisterBank initialization."
Update lambda function static auto InitializeRegisterBankOnce = [this](const auto &TRI) { with static auto InitializeRegisterBankOnce = [&]() {
Capture reference instead of passing argument, as there are buildbot compiling errors related when passing argument.
show more ...
|
Revision tags: llvmorg-10.0.0-rc1 |
|
#
2ec95457 |
| 29-Jan-2020 |
Huihui Zhang <huihuiz@quicinc.com> |
Revert "[ARM] Fix data race on RegisterBank initialization."
There looks to be buildbot failure related.
This reverts commit 91618d940ea3009d7e1489df4c8ca12017a0f612.
|
#
91618d94 |
| 29-Jan-2020 |
Huihui Zhang <huihuiz@quicinc.com> |
[ARM] Fix data race on RegisterBank initialization.
Summary: The initialization of RegisterBank needs to be done only once. The logic of AlreadyInit has data race, use llvm::call_once instead.
This
[ARM] Fix data race on RegisterBank initialization.
Summary: The initialization of RegisterBank needs to be done only once. The logic of AlreadyInit has data race, use llvm::call_once instead.
This is continuing work of D73587.
Reviewers: arsenm, rovka, dsanders, t.p.northover, efriedma, apazos
Reviewed By: arsenm
Subscribers: wdng, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73605
show more ...
|
Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
#
21309eaf |
| 09-Nov-2019 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
GlobalISel: Add type argument to getRegBankFromRegClass
AMDGPU can't unambiguously go back from the selected instruction register class to the register bank without knowing if this was used in a boo
GlobalISel: Add type argument to getRegBankFromRegClass
AMDGPU can't unambiguously go back from the selected instruction register class to the register bank without knowing if this was used in a boolean context.
show more ...
|
#
e74c5b96 |
| 01-Nov-2019 |
Daniel Sanders <daniel_l_sanders@apple.com> |
[globalisel] Rename G_GEP to G_PTR_ADD
Summary: G_GEP is rather poorly named. It's a simple pointer+scalar addition and doesn't support any of the complexities of getelementptr. I therefore propose
[globalisel] Rename G_GEP to G_PTR_ADD
Summary: G_GEP is rather poorly named. It's a simple pointer+scalar addition and doesn't support any of the complexities of getelementptr. I therefore propose that we rename it. There's a G_PTR_MASK so let's follow that convention and go with G_PTR_ADD
Reviewers: volkan, aditya_nandakumar, bogner, rovka, arsenm
Subscribers: sdardis, jvesely, wdng, nhaehnle, hiraditya, jrtc27, atanasyan, arphaman, Petar.Avramovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69734
show more ...
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3 |
|
#
25f08a17 |
| 20-Jun-2019 |
Eli Friedman <efriedma@quicinc.com> |
[ARM GlobalISel] Add support for s64 G_ADD and G_SUB.
Teach RegisterBankInfo to use the correct register class, and tell the legalizer it's legal. Everything else just works.
The one thing that's
[ARM GlobalISel] Add support for s64 G_ADD and G_SUB.
Teach RegisterBankInfo to use the correct register class, and tell the legalizer it's legal. Everything else just works.
The one thing that's slightly weird about this compared to SelectionDAG isel is that legalization can't distinguish between i64 and <1 x i64>, so we might end up with more NEON instructions than the user expects.
Differential Revision: https://reviews.llvm.org/D63585
llvm-svn: 363989
show more ...
|
#
286e1d2c |
| 13-Jun-2019 |
Simon Tatham <simon.tatham@arm.com> |
[ARM] Set up infrastructure for MVE vector instructions.
This commit prepares the way to start adding the main collection of MVE instructions, which operate on the 128-bit vector registers.
The mos
[ARM] Set up infrastructure for MVE vector instructions.
This commit prepares the way to start adding the main collection of MVE instructions, which operate on the 128-bit vector registers.
The most obvious thing that's needed, and the simplest, is to add the MQPR register class, which is like the existing QPR except that it has fewer registers in it.
The more complicated part: MVE defines a system of vector predication, in which instructions operating on 128-bit vector registers can be constrained to operate on only a subset of the lanes, using a system of prefix instructions similar to the existing Thumb IT, in that you have one prefix instruction which designates up to 4 following instructions as subject to predication, and within that sequence, the predicate can be inverted by means of T/E suffixes ('Then' / 'Else').
To support instructions of this type, we've added two new Tablegen classes `vpred_n` and `vpred_r` for standard clusters of MC operands to add to a predicated instruction. Both include a flag indicating how the instruction is predicated at all (options are T, E and 'not predicated'), and an input register field for the register controlling the set of active lanes. They differ from each other in that `vpred_r` also includes an input operand for the previous value of the output register, for instructions that leave inactive lanes unchanged. `vpred_n` lacks that extra operand; it will be used for instructions that don't preserve inactive lanes in their output register (either because inactive lanes are zeroed, as the MVE load instructions do, or because the output register isn't a vector at all).
This commit also adds the family of prefix instructions themselves (VPT / VPST), and all the machinery needed to work with them in assembly and disassembly (e.g. generating the 't' and 'e' mnemonic suffixes on disassembled instructions within a predicated block)
I've added a couple of demo instructions that derive from the new Tablegen base classes and use those two operand clusters. The bulk of the vector instructions will come in followup commits small enough to be manageable. (One exception is that I've added the full version of `isMnemonicVPTPredicable` in the AsmParser, because it seemed pointless to carefully split it up.)
Reviewers: dmgreen, samparker, SjoerdMeijer, t.p.northover
Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62669
llvm-svn: 363258
show more ...
|
#
7bd5c55c |
| 11-Jun-2019 |
Mikhail Maltsev <mikhail.maltsev@arm.com> |
[ARM] First MVE instructions: scalar shifts.
This introduces a new decoding table for MVE instructions, and starts by adding the family of scalar shift instructions that are part of the MVE architec
[ARM] First MVE instructions: scalar shifts.
This introduces a new decoding table for MVE instructions, and starts by adding the family of scalar shift instructions that are part of the MVE architecture extension: saturating shifts within a single GPR, and long shifts across a pair of GPRs (both saturating and normal).
Some of these shift instructions have only 3-bit register fields in the encoding, with the low bit fixed. So they can only address an odd or even numbered GPR (depending on the operand), and therefore I add two new register classes, GPREven and GPROdd.
Differential Revision: https://reviews.llvm.org/D62668
Change-Id: Iad95d5f83d26aef70c674027a184a6b1e0098d33 llvm-svn: 363051
show more ...
|
Revision tags: llvmorg-8.0.1-rc2 |
|
#
760df47b |
| 28-May-2019 |
Simon Tatham <simon.tatham@arm.com> |
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are reversed: each one indicates the _lack_ of support for something in the arch
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are reversed: each one indicates the _lack_ of support for something in the architecture, rather than the presence. As a consequence, you don't get the behavior you want if you combine two sets of feature bits.
Each SubtargetFeature for an FP architecture version now comes in four versions, one for each combination of those options. So you can still say (for example) '+vfp2' in a feature string and it will mean what it's always meant, but there's a new string '+vfp2d16sp' meaning the version without those extra options.
A lot of this change is just mechanically replacing positive checks for the old features with negative checks for the new ones. But one more interesting change is that I've rearranged getFPUFeatures() so that the main FPU feature is appended to the output list *before* rather than after the features derived from the Restriction field, so that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
show more ...
|
Revision tags: llvmorg-8.0.1-rc1 |
|
#
35314533 |
| 09-May-2019 |
Diana Picus <diana.picus@linaro.org> |
[ARM GlobalISel] Map DBG_VALUE for types != s32
...and make sure we fail elegantly for unsupported values.
s64 goes into DPR, anything <= 32 into GPR.
llvm-svn: 360321
|
#
165846b0 |
| 10-Apr-2019 |
Diana Picus <diana.picus@linaro.org> |
[ARM GlobalISel] Map G_FCONSTANT
llvm-svn: 358061
|
#
153c3887 |
| 04-Apr-2019 |
Diana Picus <diana.picus@linaro.org> |
[ARM GlobalISel] Support DBG_VALUE
Make sure we can map and select DBG_VALUE.
llvm-svn: 357681
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|