[Bug rtl-optimization/51933] [4.7 regression] wrong code due to -free

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Sat Jan 21 19:57:00 GMT 2012


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51933

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-21 18:40:23 UTC ---
That unfortunately slightly pessimizes it.  E.g. on i686-linux bootstrap
on:
../../gcc/config/i386/i386.c ix86_memory_move_cost
../../gcc/config/i386/i386.c ix86_register_move_cost
../../../../libgfortran/io/write.c write_float
../../../libgfortran/io/write.c write_float
s-regpat.adb system__regpat__dump_until
/usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-vpackuswb-1.c do_test
/usr/src/gcc/gcc/testsuite/gcc.target/i386/sse2-packuswb-1.c do_test
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/1.cc _S_tree_concat
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/2.cc _S_tree_concat
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/3.cc _S_tree_concat
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/44963.cc _S_tree_concat
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/4.cc _S_tree_concat
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/pthread7-rope.cc _S_tree_concat
and on x86_64-linux bootstrap sans regtest:
../../gcc/ada/par.adb par__prag__process_restrictions_or_restriction_warnings
../../gcc/config/i386/i386.c ix86_memory_move_cost
../../gcc/config/i386/i386.c ix86_register_move_cost
../../gcc/java/jcf-parse.c rewrite_reflection_indexes
../../../libgfortran/io/write.c write_float
s-regpat.adb system__regpat__dump_until

The problem is if the def insn satisfies is_cond_copy_insn, then it can be in a
wider mode, yet all definitions could still be in a narrower mode.
So, perhaps we'd need to have a recursive function that for is_cond_copy_insn
defs calls get_defs on both args and recurses, checking mode of real
definitions only.  Not sure if we'd need also this is_insn_visited array for it
to avoid recursing infinitely.

BTW, for 4.8, I guess a couple of ree.c cleanups will be needed, e.g. several
functions allocate and free way too many heap allocated vectors, I guess if we
allocate them in the caller (or caller's caller) and just pass addresses of
those vectors around, we could just VEC_truncate the vectors and avoid the
permanent malloc/free.



More information about the Gcc-bugs mailing list