[Bug c/112102] New: Inefficient Integer multiplication on MIPS processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
Bug ID: 112102
Summary: Inefficient Integer multiplication on MIPS processors
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kazeemanuar at googlemail dot com
Target Milestone: ---
Running integer multiplication with the -Os flag enabled can generate 2
unnecessary NOP instructions. This increases the cost of integer multiplication
from 7 to 9 cycles in most cases.
Example code:
int test(int a, int b, int c, int d)
{
return 788*a + 789 * b + 187 + c + d;
}
output:
li $2,788
mult$4,$2
li $2,789 <--- could be moved down into one of the NOPs
mflo$4
nop
nop
mult$5,$2
mflo$5
addu$4,$4,$5
addiu $4,$4,187 <--- could be moved up into one of the NOPs
addu$4,$4,$6 <--- could be moved up into one of the NOPs
jr $31
addu$2,$4,$7
This happens on all GCC versions as far as I can tell.
Compiler explorer link: https://godbolt.org/z/M3x3s3KhM
[Bug c/112102] Inefficient Integer multiplication on MIPS processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102 --- Comment #1 from Kaze Emanuar --- Ignore the line about cycle counts. That was only applicable to my use case before I realized GCC does this for all MIPS architectures. Sorry!
[Bug target/112102] Inefficient Integer multiplication on MIPS processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102 --- Comment #4 from Kaze Emanuar --- I'm using the vr4300 (Nintendo 64). It does have the hazard between mult and mflos. MULT can't be within 2 instructions of the MFLO. This shouldn't be an issue here though since there were 3 instructions available to put into the 2 NOP slots the MULT<>MFLO clash caused.
[Bug target/112102] Inefficient Integer multiplication on MIPS processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102 --- Comment #8 from Kaze Emanuar --- This code is just an example, but I have seen this issue appear in many of my collision functions. I agree it's not a huge issue in my use case, but it'd still be cool to have this work well. I can work around it with inline assembly if this is not deemed an important enough issue to address.
