https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
Vineet Gupta changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment #
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 prune
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
Insn
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&action=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 constan
To be clear, `li rx, 4096' isn't unsupported: it's a
very-much-supported idiom for `lui rx, 1`.
On Mon, Jul 11, 2022 at 11:45 PM rguenth at gcc dot gnu.org via
Gcc-bugs wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
>
> --- Comment #5 from Richard Biener ---
> So why do we even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #6 from Andrew Waterman ---
To be clear, `li rx, 4096' isn't unsupported: it's a
very-much-supported idiom for `lui rx, 1`.
On Mon, Jul 11, 2022 at 11:45 PM rguenth at gcc dot gnu.org via
Gcc-bugs wrote:
>
> https://gcc.gnu.org/bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106265
--- Comment #5 from Richard Biener ---
So why do we even emit unsupported 'li 4096' and leave it to the linker to
"optimize(?)"? At least the cost of this should be reflected - IIRC powerpc
recently got improvements for similar cases by changin
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 a3
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 th
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 *)&ao)[k] + *(double *)((char *)0)[12] +
#(insn 2662 1711 76 (set (reg:DI 12 a2
13 matches
Mail list logo
