Revision tags: llvmorg-21-init |
|
#
d6e0798a |
| 24-Jan-2025 |
yingopq <115543042+yingopq@users.noreply.github.com> |
[Mips] Add the missing judgment when processing function handleMFLOSlot (#121463)
In function handleMFLOSlot, we may get a variable LastInstInFunction
with a value of true from function getNextMach
[Mips] Add the missing judgment when processing function handleMFLOSlot (#121463)
In function handleMFLOSlot, we may get a variable LastInstInFunction
with a value of true from function getNextMachineInstr and IInSlot may
be null which would trigger an assert.
So we need to skip this case.
Fix #118223.
show more ...
|
Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
73e89cf6 |
| 16-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[Mips] Remove unused includes (NFC) (#116499)
Identified with misc-include-cleaner.
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1 |
|
#
677177bb |
| 23-Sep-2024 |
yingopq <115543042+yingopq@users.noreply.github.com> |
[Mips] Fix mfhi/mflo hazard miscompilation about div and mult (#91449)
Fix issue1: In mips1-4, require a minimum of 2 instructions between a
mflo/mfhi and the next mul/dmult/div/ddiv/divu/ddivu ins
[Mips] Fix mfhi/mflo hazard miscompilation about div and mult (#91449)
Fix issue1: In mips1-4, require a minimum of 2 instructions between a
mflo/mfhi and the next mul/dmult/div/ddiv/divu/ddivu instruction.
Fix issue2: In mips1-4, should not put mflo into the delay slot for the
return.
Fix https://github.com/llvm/llvm-project/issues/81291
show more ...
|
Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, 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 |
|
#
053c0ad4 |
| 30-Jan-2024 |
Kazu Hirata <kazu@google.com> |
[Mips] Use a range-based for loop (NFC)
|
Revision tags: llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, 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, 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 |
|
#
ad73ce31 |
| 26-May-2022 |
Zongwei Lan <lanzongwei541@gmail.com> |
[Target] use getSubtarget<> instead of static_cast<>(getSubtarget())
Differential Revision: https://reviews.llvm.org/D125391
|
Revision tags: llvmorg-14.0.4 |
|
#
ba1c70c6 |
| 08-May-2022 |
Simon Dardis <simon.dardis@gmail.com> |
[MIPS] Remove an incorrect microMIPS instruction alias
The microMIPS instruction set is compatible with the MIPS instruction set at the assembly level but not in terms of encodings. `nop` in microMI
[MIPS] Remove an incorrect microMIPS instruction alias
The microMIPS instruction set is compatible with the MIPS instruction set at the assembly level but not in terms of encodings. `nop` in microMIPS is a special case as it has the same encoding as `nop` for MIPS.
Fix this error by reducing the usage of NOP in the MIPS backend such that only that ISA correct variants are produced.
Differential Revision: https://reviews.llvm.org/D124716
show more ...
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
#
303c1801 |
| 06-Apr-2022 |
Simon Dardis <simon.dardis@gmail.com> |
[MIPS] Initial support for MIPS-I load delay slots
LLVM so far has only supported the MIPS-II and above architectures. MIPS-II is pretty close to MIPS-I, the major difference being that "load" instr
[MIPS] Initial support for MIPS-I load delay slots
LLVM so far has only supported the MIPS-II and above architectures. MIPS-II is pretty close to MIPS-I, the major difference being that "load" instructions always take one extra instruction slot to propogate to registers. This patch adds support for MIPS-I by adding hazard handling for load delay slots, alongside MIPSR6 forbidden slots and FPU slots, inserting a NOP instruction between a load and any instruction immediately following that reads the load's destination register. I also included a simple regression test. Since no existing tests target MIPS-I, those all still pass.
Issue ref: https://github.com/simias/psx-sdk-rs/issues/1
I also tested by building a simple demo app with Clang and running it in an emulator.
Patch by: @impiaaa
Differential Revision: https://reviews.llvm.org/D122427
show more ...
|
#
37b37838 |
| 16-Mar-2022 |
Shengchen Kan <shengchen.kan@intel.com> |
[NFC][CodeGen] Rename some functions in MachineInstr.h and remove duplicated comments
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
f0f6bba5 |
| 07-Dec-2021 |
Djordje Todorovic <djordje.todorovic@syrmia.com> |
[MIPS] Add FPU Delay Slot for MIPS1/2/3
MIPS I, II, and III have delay slots for floating point comparisons and floating point register transfers (mtc1, mfc1). Currently, these are not taken into ac
[MIPS] Add FPU Delay Slot for MIPS1/2/3
MIPS I, II, and III have delay slots for floating point comparisons and floating point register transfers (mtc1, mfc1). Currently, these are not taken into account and thus broken code may be generated on these targets. This patch inserts nops as necessary, while attempting to leave the current instruction if it is safe to stay.
The tests in this patch were updated by @sajattack
Patch by @overdrivenpotato (Marko Mijalkovic <marko.mijalkovic97@gmail.com>)
Differential Revision: https://reviews.llvm.org/D115127
show more ...
|
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, 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 |
|
#
bcbd60ae |
| 27-Mar-2020 |
Djordje Todorovic <djordje.todorovic@syrmia.com> |
[Mips] Make MipsBranchExpansion aware of BBIT family of branch
Octeon branches (bbit0/bbit032/bbit1/bbit132) have an immediate operand, so it is legal to have such replacement within MipsBranchExpan
[Mips] Make MipsBranchExpansion aware of BBIT family of branch
Octeon branches (bbit0/bbit032/bbit1/bbit132) have an immediate operand, so it is legal to have such replacement within MipsBranchExpansion::replaceBranch().
According to the specification, a branch (e.g. bbit0 ) looks like:
bbit0 rs p offset // p is an immediate operand if !rs<p> then branch
Without this patch, an assertion triggers in the method, and the problem has been found in the real example.
Differential Revision: https://reviews.llvm.org/D76842
show more ...
|
Revision tags: 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, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5 |
|
#
97264366 |
| 11-Sep-2019 |
Guillaume Chatelet <gchatelet@google.com> |
[Alignment][NFC] use llvm::Align for AsmPrinter::EmitAlignment
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail
[Alignment][NFC] use llvm::Align for AsmPrinter::EmitAlignment
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: dschuff, sdardis, nemanjai, hiraditya, kbarton, jrtc27, MaskRay, atanasyan, jsji, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67443
llvm-svn: 371616
show more ...
|
Revision tags: llvmorg-9.0.0-rc4 |
|
#
aff45e4b |
| 05-Sep-2019 |
Guillaume Chatelet <gchatelet@google.com> |
[LLVM][Alignment] Make functions using log of alignment explicit
Summary: This patch renames functions that takes or returns alignment as log2, this patch will help with the transition to llvm::Alig
[LLVM][Alignment] Make functions using log of alignment explicit
Summary: This patch renames functions that takes or returns alignment as log2, this patch will help with the transition to llvm::Align. The renaming makes it explicit that we deal with log(alignment) instead of a power of two alignment. A few renames uncovered dubious assignments:
- `MirParser`/`MirPrinter` was expecting powers of two but `MachineFunction` and `MachineBasicBlock` were using deal with log2(align). This patch fixes it and updates the documentation. - `MachineBlockPlacement` exposes two flags (`align-all-blocks` and `align-all-nofallthru-blocks`) supposedly interpreted as power of two alignments, internally these values are interpreted as log2(align). This patch updates the documentation, - `MachineFunctionexposes` exposes `align-all-functions` also interpreted as power of two alignment, internally this value is interpreted as log2(align). This patch updates the documentation,
Reviewers: lattner, thegameg, courbet
Subscribers: dschuff, arsenm, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, Jim, s.egerton, llvm-commits, courbet
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65945
llvm-svn: 371045
show more ...
|
Revision tags: 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, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, 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 ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
#
8d7c3517 |
| 05-Nov-2018 |
Stefan Maksimovic <stefan.maksimovic@mips.com> |
[Mips] Supplement long branch pseudo instructions
Expand on LONG_BRANCH_LUi and LONG_BRANCH_(D)ADDiu pseudo instructions by creating variants which support less operands/accept GPR64Opnds as their o
[Mips] Supplement long branch pseudo instructions
Expand on LONG_BRANCH_LUi and LONG_BRANCH_(D)ADDiu pseudo instructions by creating variants which support less operands/accept GPR64Opnds as their operand in order to appease the machine verifier pass.
Differential Revision: https://reviews.llvm.org/D53977
llvm-svn: 346133
show more ...
|
Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
#
cd0c50e3 |
| 01-Nov-2018 |
Stefan Maksimovic <stefan.maksimovic@mips.com> |
[Mips] Conditionally remove successor block
In MipsBranchExpansion::splitMBB, upon splitting a block with two direct branches, remove the successor of the newly created block (which inherits success
[Mips] Conditionally remove successor block
In MipsBranchExpansion::splitMBB, upon splitting a block with two direct branches, remove the successor of the newly created block (which inherits successors from the original block) which is pointed to by the last branch in the original block only if the targets of two branches differ.
This is to fix the failing test when ran with -verify-machineinstrs enabled.
Differential Revision: https://reviews.llvm.org/D53756
llvm-svn: 345821
show more ...
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2 |
|
#
949a17c0 |
| 07-Aug-2018 |
Aleksandar Beserminji <abeserminji@wavecomp.com> |
[mips] Handle branch expansion corner cases
When potential jump instruction and target are in the same segment, use jump instruction with immediate field.
In cases where offset does not fit immedia
[mips] Handle branch expansion corner cases
When potential jump instruction and target are in the same segment, use jump instruction with immediate field.
In cases where offset does not fit immediate value of a bc/j instructions, offset is stored into register, and then jump register instruction is used.
Differential Revision: https://reviews.llvm.org/D48019
llvm-svn: 339126
show more ...
|
Revision tags: llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3 |
|
#
8acdc102 |
| 12-Jun-2018 |
Aleksandar Beserminji <Aleksandar.Beserminji@mips.com> |
[mips] Extend LONG_BRANCH_LUi/ADDiu with extra parameter
Extend LONG_BRANCH_LUi and LONG_BRANCH_ADDiu pseudo instructions with additional flag, so instead of always lowering to lui %hi(...), addiu %
[mips] Extend LONG_BRANCH_LUi/ADDiu with extra parameter
Extend LONG_BRANCH_LUi and LONG_BRANCH_ADDiu pseudo instructions with additional flag, so instead of always lowering to lui %hi(...), addiu %lo(...) or addiu %hi(...), now they can lower to either %lo, %hi, %higher or %highest depending on the added flag.
Differential Revision: https://reviews.llvm.org/D47941
llvm-svn: 334490
show more ...
|
Revision tags: llvmorg-6.0.1-rc2 |
|
#
a5f75518 |
| 22-May-2018 |
Aleksandar Beserminji <Aleksandar.Beserminji@mips.com> |
[mips] Merge MipsLongBranch and MipsHazardSchedule passes
MipsLongBranchPass and MipsHazardSchedule passes are joined to one pass because of mutual conflict. When MipsHazardSchedule inserts 'nop's,
[mips] Merge MipsLongBranch and MipsHazardSchedule passes
MipsLongBranchPass and MipsHazardSchedule passes are joined to one pass because of mutual conflict. When MipsHazardSchedule inserts 'nop's, it potentially breaks some jumps, so they have to be expanded to long branches. When some branch is expanded to long branch, it potentially creates a hazard situation, which should be fixed by adding nops. New pass is called MipsBranchExpansion, it combines these two passes, and runs them alternately until one of them reports no changes were made.
Differential Revision: https://reviews.llvm.org/D46641
llvm-svn: 332977
show more ...
|
#
de7be5e4 |
| 21-May-2018 |
Aleksandar Beserminji <Aleksandar.Beserminji@mips.com> |
[mips] Merge MipsLongBranch and MipsHazardSchedule passes
MipsLongBranchPass and MipsHazardSchedule passes are joined to one pass because of mutual conflict. When MipsHazardSchedule inserts 'nop's,
[mips] Merge MipsLongBranch and MipsHazardSchedule passes
MipsLongBranchPass and MipsHazardSchedule passes are joined to one pass because of mutual conflict. When MipsHazardSchedule inserts 'nop's, it potentially breaks some jumps, so they have to be expanded to long branches. When some branch is expanded to long branch, it potentially creates a hazard situation, which should be fixed by adding nops. New pass is called MipsBranchExpansion, it combines these two passes, and runs them alternately until one of them reports no changes were made.
Differential Revision: https://reviews.llvm.org/D46641
llvm-svn: 332834
show more ...
|