This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [3.3/3.4/3.5 Regression] Performace regression: poor optimization of const memory


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]