This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: One line performance tweak
On Fri, Jan 05, 2001 at 01:04:28PM -0800, Mark Mitchell wrote:
> >>>>> "Zack" == Zack Weinberg <zackw@stanford.edu> writes:
>
> Zack> I will bootstrap this along with a fix for cpplib's --help
> Zack> problem (reported twice yesterday) - assuming it succeeds,
> Zack> OK to apply?
>
> Definitely. Nice catch.
It's still not enough for Peter's test case, though. -ftime-report,
all entries consuming at least 1% of user time, with patch:
expand : 802.36 (83%) usr 0.26 ( 4%) sys 802.73 (83%) wall
parser : 27.73 ( 3%) usr 0.42 ( 7%) sys 28.25 ( 3%) wall
jump : 19.63 ( 2%) usr 0.58 ( 9%) sys 20.27 ( 2%) wall
garbage collection : 16.94 ( 2%) usr 0.01 ( 0%) sys 16.96 ( 2%) wall
scheduling 2 : 16.19 ( 2%) usr 0.49 ( 8%) sys 16.70 ( 2%) wall
loop analysis : 14.60 ( 2%) usr 3.24 (52%) sys 17.84 ( 2%) wall
CSE : 10.87 ( 1%) usr 0.02 ( 0%) sys 10.90 ( 1%) wall
global CSE : 11.24 ( 1%) usr 0.20 ( 3%) sys 11.44 ( 1%) wall
integration : 8.58 ( 1%) usr 0.05 ( 1%) sys 8.64 ( 1%) wall
global alloc : 6.04 ( 1%) usr 0.10 ( 2%) sys 6.17 ( 1%) wall
and the profiler still says >60% of runtime in fixup_var_refs etc.
This isn't to say that 10% improvement on a one-line change is bad,
just to encourage people not to forget about this test case.
Unfortunately I don't see any easy way to speed up fixup_var_refs. It
scans the entire insn chain looking for references to a specific RTX
(usually a REG, I imagine) and munges them - in different ways
depending on context, so we couldn't just use shared structure and
modify it once. There's something going on with a hash table mapping
REGs to INSN_LISTs of their uses, but it doesn't seem to be used very
often.
This is going on during RTL generation ("expand" phase) so we don't
have any nice data-flow information to help out, either.
zw