From: Trevor Saunders <tbsaunde+...@tbsaunde.org> Hi,
These few patches to get rid of rtx insn and expr lists should be pretty un controvertial. In each case the list is clearly used as a stack and using a vec as a stack is clearly the same. In theory I would expect if anything this helps performance since it isn't necessary to malloc every time a node is added, however the data is less clear. Here are times for O2 and O0 for fold-const.ii from gcc, and Unified_js_src_cpp_32.ii from Spider Monkey. These are best of 3 based on user time. fold const O2 new real 0m5.034s user 0m3.408s sys 0m0.364s fold const O2 old real 0m4.012s user 0m3.420s sys 0m0.340s fold const O0 new real 0m1.637s user 0m1.124s sys 0m0.280s fold const O0 old real 0m2.483s user 0m1.092s sys 0m0.280s mozjs O2 new real 0m15.565s user 0m12.420s sys 0m1.536s mozjs O2 old real 0m13.662s user 0m12.136s sys 0m1.440s mozjs O0 new real 0m9.860s user 0m6.796s sys 0m1.368s mozjs O0 old real 0m8.922s user 0m6.888s sys 0m1.388s So a couple got about .3s slower, and others got about .1 faster, I'm not really sure but inclined to say any change is too small to easily measure. bootstrapped + regtested patches individually on x86_64-linux-gnu, ok? Trev Trevor Saunders (6): make antic_stores a vec<rtx_insn *> remove unused loads rtx_insn_list make stores rtx_insn_list a vec make side_effects a vec<rtx> make pattern_regs a vec loop-iv.c: make cond_list a vec gcc/gcse.c | 36 ++++++------------- gcc/loop-iv.c | 55 ++++++++++------------------ gcc/store-motion.c | 103 +++++++++++++++++++++++++---------------------------- gcc/var-tracking.c | 33 ++++++++--------- 4 files changed, 90 insertions(+), 137 deletions(-) -- 2.7.4