On 09/01/14 02:13, Zhenqiang Chen wrote:
To split live-range of register, split_live_ranges_for_shrink_wrap will
introduce additional register copies. If such copies can not be optimized by
later optimizations, it will lead to code size and performance regression.
My tests on ARM THUMB1 code size show lots of regressions due to additional
register copies. Shrink-wrap is not enabled for ARM THUMB1, so I think
split_live_ranges_for_shrink_wrap should not be called.
So has anyone looked at why IRA ends up selecting different registers
for the source/dest of these copies? Odds are it's just an artifact of
the heuristics in use, but I'd like to make sure there isn't something
inherently wrong happening in IRA that's causing it to not tie the
source/dest of those copies.
ChangeLog:
2014-09-01 Zhenqiang Chen <zhenqiang.c...@arm.com>
* shrink-wrap.h: #define SHRINK_WRAPPING_ENABLED.
* ira.c: #include "shrink-wrap.h"
(split_live_ranges_for_shrink_wrap): Use SHRINK_WRAPPING_ENABLED.
* ifcvt.c: #include "shrink-wrap.h"
(dead_or_predicable): Use SHRINK_WRAPPING_ENABLED.
testsuite/ChangeLog:
2014-09-01 Zhenqiang Chen <zhenqiang.c...@arm.com>
* gcc.target/arm/split-live-ranges-for-shrink-wrap.c: New test.
Thanks. OK for the trunk.
As noted above, it'd may be worth spending a little time looking at the
regressions without this patch installed to see why IRA isn't doing a
good job of tying the source/dest of these copies together -- perhaps
there's something that's been overlooked and fixing it may be beneficial.
jeff
