https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #14 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #12)
> Here is something to look into:
> #define const1 0x0101010101010101ULL
> #define const0 const1
> unsigned long long f(unsigned long long occ, const unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #13 from Vineet Gupta ---
Ok it seems I missed _some_ improvement with prev change, although not ideal
still.
With 2e886eef7f2b
li a0,0x0101_
addia0,a0,0x0101
sllia0,a0,16
addi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #11 from Vineet Gupta ---
With change suggested by @pinksia, I do see that in split1,
riscv_move_integer() -> riscv_split_integer() is now called.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #10 from Vineet Gupta ---
I tried removing the in_splitter check (in 2 places), but no change in
results.
@@ -1313,7 +1313,7 @@ riscv_force_temporary (rtx dest, rtx value, bool
in_splitter)
- if (can_create_pseudo_p () &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #4 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #2)
> If this was about -Os, then I would say yes this is a big code bloat but
> this is about -O2.
But this is not so much about code bloat, we see 3.5% additional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #3 from Vineet Gupta ---
We start off with following:
(insn 18 17 19 2 (set (reg:DI 154)
(mem/u/c:DI (reg/f:DI 155) [0 S8 A64])) "...":9:8 179 {*movdi_64bit}
(expr_list:REG_DEAD (reg/f:DI 155)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
Bug ID: 109279
Summary: [13 Regression] RISC-V: complex constants synthesized
vs. fetching from constant pool
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106439
Bug ID: 106439
Summary: RISC-V suboptimal codegen for large constants
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #10 from Vineet Gupta ---
Created a small test case which emulates generation of 2 split consts.
void foo(void)
{
bar(2072, 2096);
}
253r.expand has 4 instructions: Pair of LI 4096 + ADDI for each const.
260r.fwprop1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #9 from Vineet Gupta ---
The redundant Insn 2660 is reload inserted for Insn 1717
1717: r1871:DI=frame:DI+r2813:DI
Inserting insn reload before:
2660: r2814:DI=0x1000
2661: r2813:DI=r2814:DI-0x7e8
REG_EQUAL 0x818
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #8 from Vineet Gupta ---
Created attachment 53332
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53332=edit
Full reload output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #7 from Vineet Gupta ---
(In reply to Richard Biener from comment #5)
> So why do we even emit unsupported 'li 4096' and leave it to the linker to
> "optimize(?)"?
li 4096 is really a pseudo-op - LUI is used to build 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #4 from Vineet Gupta ---
Going back to first dump (upstream 6abe341558a w/o riscv_rtx_costs() adj): the
3rd instruction addi is marking a2 REG_DEAD at 315 cprop.hardreg
--->8 314r.rnreg
(insn 2663 2662 1714 3 (set (reg:DI 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #3 from Vineet Gupta ---
Digging into RTL dumps, the li instructions are introduced by 300r reload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #2 from Vineet Gupta ---
I've experimented with riscv_rtx_costs() setting cost of const to 1 as
discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596. This does
reduce the number of li 4096 instances to 10 (from 14), but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #1 from Vineet Gupta ---
Analyzed a section of -dP dump where reg a2 is setup with exact same value
while being live.
rhs-cred.cc:42: (*(double *)((char *))[k] + *(double *)((char *)0)[12] +
#(insn 2662 1711 76 (set (reg:DI 12 a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
Bug ID: 106265
Summary: RISC-V SPEC2017 507.cactu code bloat due to address
generation
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 105666, which changed state.
Bug 105666 Summary: RISC-V 507.cactuBSSN_r build has costly FMV instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105666
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105666
Vineet Gupta changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674
Vineet Gupta changed:
What|Removed |Added
CC||kito at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105666
--- Comment #3 from Vineet Gupta ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595428.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105666
Vineet Gupta changed:
What|Removed |Added
CC||vineet.gupta at linux dot dev
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105666
Bug ID: 105666
Summary: RISC-V 507.cactuBSSN_r build has costly FMV
instructions
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
23 matches
Mail list logo
