https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #41 from Levy <admin at levyhsu dot com> ---
When putting the same debug_rtx(addr) at the first line of riscv_address_cost()
Unpatched one outputs:
(plus:DI (reg/f:DI 15 a5 [88])
(const_int 32 [0x20]))
(plus:DI (reg:DI 10 a0 [92])
(const_int 800 [0x320]))
(plus:DI (reg/f:DI 15 a5 [88])
(const_int 36 [0x24]))
(plus:DI (reg:DI 10 a0 [92])
(const_int 804 [0x324]))
.......
Patched one outputs nothing. what it means to me is that riscv backend,
something like:
(sign_extend:DI (mem:SI (plus:DI (reg:DI 93)
is never passed to riscv_address_cost(), unlike:
(mem:SI (plus:DI (reg:DI 89)
so whether riscv_mshorten_memrefs is set or not doesn't really matter here.
Then I traced back to where address_cost() is called,
1.address_cost() is called by riscv_new_address_profitable_p() in riscv.c
2.riscv_new_address_profitable_p() is called by attempt_change() in
sched-deps.c
And since I'm not that familiar with struct mem_inc_info, this of trace could
be wrong:
3.attempt_change() is called by find_inc() in sched-deps.c
....(Still tracing)
------------------------------------------------------
Also since Arm can handle sign/zero/extend with subreg under -Os, I had a quick
search on arm.c
in arm_address_cost(), rtx here were passed as x, not addr (which addr may be
XEXP (mem, 0)).
So GET_CODE (x) cam be used to determine whether it has a
MEM/LABEL_REF/SYMBOL_REF... at front. Then cost can be vary from 0 all the way
to 10.
This also worth some investigation to see how -Os works on arm side.
------------------------------------------------------
Need some time to work on it.
