https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #61 from CVS Commits ---
The master branch has been updated by Jim Wilson :
https://gcc.gnu.org/g:18fabc35f47f0abf4ec14d147098ec4e0734d2a3
commit r11-7237-g18fabc35f47f0abf4ec14d147098ec4e0734d2a3
Author: Levy Hsu
Date: Sat Feb 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #60 from CVS Commits ---
The master branch has been updated by Jim Wilson :
https://gcc.gnu.org/g:a4953810bac524e19126a2745c75fed58db962c2
commit r11-7236-ga4953810bac524e19126a2745c75fed58db962c2
Author: Jim Wilson
Date: Sat Feb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #59 from jiawei ---
Hi Kito,
Okay, I will retest the benchmark on gem5.
发自我的小米手机在 "kito at gcc dot gnu.org"
，2020年12月25日 上午11:31写道：
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #58 from Ki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #58 from Kito Cheng ---
Hi jiawei:
I would suggest you just using inst count rather than cycle or time for
measuring benchmark if you using qemu, since qemu is functional simulator not
cycle accurate neither nearly-cycle accurate sim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #57 from Levy ---
Thank you JiaWei for the CoreMark-Pro result.
Personally, I agree with Jim, since changing the split behaviour of try_combine
in the combine.c could affect other platforms, theoretically, we can fix it
with platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #56 from jiawei ---
Hi Kito,
I test the performance data on qemu-riscv64, and compile the benchmark
with riscv-unknown-linux-gnu-gcc -Os.
All the modify is set in /coremark-pro/util/make/
to change the toolchain and ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #55 from Kito Cheng ---
Hi jiawei:
Thanks for the data, the performance changing for coremark-pro seems
interesting, could you find which part generate different code after the patch?
And I am curious what the platform you used for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #54 from jiawei ---
Hi Jim.
I had finished the test on the benchmark Coremark-pro.And it shows that the
patch doesn't accidentally increase code size.
This test with the args "XCMD='-c4' certify-all", and the result shows follow:
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #53 from jiawei ---
Hi Jim,
Levy had asked me to help about the test. I was resigned on EEMBC and
waiting acess for more benchmarks. Now I am testing on csibe and
coremax-pro. I think will lineout the result in this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #52 from Jim Wilson ---
I did some simple testing of my patch alone. I modified the
riscv-gnu-toolchain makefile to use -Os to build all libraries, built a
rv32imac/ilp32 toolchain, and looked at library code size. I see a few cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #51 from Jim Wilson ---
Created attachment 49773
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49773&action=edit
untested fix to use instead of levy's combine.c patch
Needs testing without Levy's patch to make sure it doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #50 from Jim Wilson ---
The combine change is inconvenient. We can't do that in stage3, and it means
we need to make sure that this doesn't break other targets.
If the combine change is a good idea, then I think you can just modify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
Levy changed:
What|Removed |Added
Attachment #49543|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #48 from Levy ---
Created attachment 49757
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49757&action=edit
Initial V1 patch on combine.c
Three patches together:
= Summary of gcc testsuite =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #47 from Levy ---
where insns are merged:
In combine.c (pass_combine)
rest_of_handle_combine()
calls:
combine_instructions()
calls:
creat_log_links() creates links of insn (768&32/36/40/44)
for both patched and unpatched version wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #46 from Levy ---
Looking at gcc/passed.def and gcc/config/riscv-passes.def:
pass_shorten_memrefs is inserted after NEXT_PASS (pass_rtl_store_motion);
NEXT_PASS (pass_rtl_store_motion);
(pass_shorten_memrefs)
NEXT_PASS (pass_cse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #45 from Levy ---
Basically crossed out the rtlanal.c and fwprop.c
I'm looking back at riscv.c. Since address_cost() was called by hook function
new_address_profitable_p(), may be some place uses this function would provide
more info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #44 from Levy ---
should_replace_address() in fwprop.c looks really interesting:
/* OLD is a memory address. Return whether it is good to use NEW instead,
for a memory access in the given MODE. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #43 from Levy ---
Thanks for pointing the hook out Jim.
for both patched and unpatched, so far I've been traced through
try_replace_in_use()
to
reload_combine_recognize_const_pattern()
to
reload_combine()
to
reload_cse_regs()
to
pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #42 from Jim Wilson ---
riscv_address_cost is a hook, so it is targetm.address_cost which is only
called from address_cost which is only called in a few places one of which is
in postreload.c so that is the one I would look at first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #41 from Levy ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #40 from Jim Wilson ---
If you look at riscv.opt you will see that the -mshorten-memrefs option sets
the variable riscv_mshorten_memrefs. If you grep for that, you will see that
it is used in riscv_address_cost in riscv.c. I believe
23 matches
Mail list logo
