This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [3.3/3.4/3.5 Regression] Performace regression: poor optimization of const memory
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 2 Mar 2004 09:46:22 +0100
- Subject: Re: [3.3/3.4/3.5 Regression] Performace regression: poor optimization of const memory
- References: <16452.24426.606568.201470@cuddles.cambridge.redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Mar 02, 2004 at 10:18:18AM +0000, Andrew Haley wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12419
>
> This regression is most unfortunate because it penalizes languages
> that use virtual function dispatch tables in const memory: AFAIK that
> means C++ and Java at least.
>
> The regression seems to have been introduced because of a double write
> problem in C++ constructors.
RTX_UNCHANGING_P is a huge can of worms.
This particular patch to maybe_set_unchanging seems to be prohibitely
restrictive, on the other side e.g. store_construcor is too liberal
and causes real bugs (it makes RTX_UNCHANGING_P mean not set at most
once, but "must be set via MEM/u store and must not be read before all
MEM/u stores are done, then it is unchanging" at least as far as I can
understand), e.g. where partly read-only partly writable struct is
made MEM/u as whole for clearing. I think in a function which initializes
a partly read-only, partly read-write object RTX_UNCHANGING_P should simply
not be used at all and if it is completely read-only, we on the other side
perhaps could use RTX_UNCHANGING_P but scan the generated code, whether
it never reads back its MEMs in the constructor setup insns. If it does,
clear the /u flags and make it !UNCHANGING. Then the test in
maybe_set_unchanging could go away.
But certainly maybe_set_unchanging should at least replace:
if ((TREE_READONLY (t) && DECL_P (t)
- && (TREE_STATIC (t) || ! AGGREGATE_TYPE_P (TREE_TYPE (t)))
+ && (TREE_STATIC (t) || DECL_EXTERNAL (t) || ! AGGREGATE_TYPE_P (TREE_TYPE (t)))
&& (TREE_CODE (t) == PARM_DECL
|| (DECL_INITIAL (t) && TREE_CONSTANT (DECL_INITIAL (t)))))
|| TREE_CODE_CLASS (TREE_CODE (t)) == 'c')
RTX_UNCHANGING_P (ref) = 1;
or something similar, that would fix Andrew's testcase. The check
should certainly not ban any decls which cannot be initialized in the
current function.
Jakub