https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90501
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #13) > That is, why's > > Index: gcc/gimple-walk.c > =================================================================== > --- gcc/gimple-walk.c (revision 271394) > +++ gcc/gimple-walk.c (working copy) > @@ -829,8 +829,7 @@ walk_stmt_load_store_addr_ops (gimple *s > gimple_call_chain (call_stmt), data); > if (visit_addr > && gimple_call_return_slot_opt_p (call_stmt) > - && gimple_call_lhs (call_stmt) != NULL_TREE > - && TREE_ADDRESSABLE (TREE_TYPE (gimple_call_lhs (call_stmt)))) > + && gimple_call_lhs (call_stmt) != NULL_TREE) > ret |= visit_addr (stmt, gimple_call_lhs (call_stmt), > gimple_call_lhs (call_stmt), data); > } > > not correct? Do we really force a new temporary to be used? > We'd need to be consistent here for inlining as well then. Tested on x86_64-linux, I see FAIL: gcc.dg/tm/memopt-4.c scan-tree-dump-times tmedge "lala.x\\\\[55\\\\] = tm_save" 1 FAIL: gcc.dg/tm/memopt-4.c scan-tree-dump-times tmedge "tm_save.[0-9_]+ = lala.x\\\\[55\\\\]" 1 FAIL: gcc.dg/tm/memopt-5.c scan-tree-dump-times tmedge "ITM_LU[0-9] \\\\(&lala.x\\\\[55\\\\]" 1 FAIL: gcc.dg/tm/memopt-6.c scan-tree-dump-times tmedge "memcpyRtWn \\\\(.*, &lacopy" 1 FAIL: gcc.dg/tm/memopt-7.c scan-tree-dump-times tmedge "lala = tm_save" 1 FAIL: gcc.dg/tm/memopt-7.c scan-tree-dump-times tmedge "tm_save.[0-9_]+ = lala" 1 didn't check if caused by the above but TM is probably to blame here (and nobody cares). There's also FAIL: gcc.dg/tree-ssa/tailcall-7.c scan-tree-dump-times tailc "Found tail call" 5 but only for -m32. This likely shows one case that would be pessimized (but then it already is for TREE_ADDRESSABLE types...).
