History log of /llvm-project/llvm/lib/Target/Mips/MipsBranchExpansion.cpp (Results 1 – 19 of 19)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...