H Joern, > Or have some target hook to make it not even bother filling delay slots > speculatively; for targets that can fully unexpose the delay slot, like SH and > ARC >= ARC700, this aspect of fill_eager_delay_slots only mucks up > schedules and increases code size.
I propose to solve the dwarf2 issues during epilogue by using the
TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P hook for ARC processors. Hence, we do
not need to emit the blockage instruction during epilogue. So, I have refactor
the patch in two patches as follows:
- The 0001-Refurbish-emitting-DWARF2-related-information-when-e.patch
is the initial patch without emitting the blockage instruction during epilogue.
- The 0002-ARC-Use-TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P-hook.patch
adds TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P hook for ARC.
Both patches are attached.
>
> More relevant ways to get data would be comparing the object files (from a
> whole toolchain library set and/or one or more big application(s)) built
> with/without the blockage insn emitted, or to benchmark it.
I did some testing here. For size, I used CSiBE testbench, and for speed, I
used coremark and dhrystone. Using a blockage or not, doesn't affect the size
or speed figures. However, using TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P hook
betters the size figures (not much, just .1%), and improves the coremark by 2%
and Dhrystone by 1%.
Hence, in the light of the new figures, I favor the above two patch solution.
Both patches are checked using dg.exp and compile.exp. Ok to submit?
Thanks,
Claudiu
0001-Refurbish-emitting-DWARF2-related-information-when-e.patch
Description: 0001-Refurbish-emitting-DWARF2-related-information-when-e.patch
0002-ARC-Use-TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P-hook.patch
Description: 0002-ARC-Use-TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P-hook.patch
