_201_compress took a 10% hit when we switched to Arnold/Grove call graph profiling; investigate

Description

Most programs either got faster or stayed unchanged. _201_compress is the only program that got significantly slower when the profiling scheme was changed. See http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf.1400/performance_report

Investigate to see if we can avoid this hit while still maintaining the gains in the other benchmarks.

Is it because of profiling overhead or a change in inlining decisions? If a change in inlining decisions, is it because we're not inlining something we should, or have we started to get an inlining we missed before and as a result the opt compiler is generating worse code for one of the two main loops in compress?

Environment

None

Status

Assignee

DaveG

Reporter

DaveG

Labels

None

Fix versions

Affects versions

Priority

Low
Configure