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
> RTX_UNCHANGING_P is a huge can of worms.
Indeed.
> 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.
Yes, store_constructor is overly optimistic. But this is now mitigated by
2003-09-12 Roger Sayle <roger@eyesopen.com>
PR optimization/8967
* alias.c (write_dependence_p): Modify to take an additional constp
argument that controls whether the UNCHANGING_RTX_P flags are used.
(anti_dependence, output_dependence): Adjust write_dependence_p
callers to pass this additional argument, to return the same result.
(unchanging_anti_dependence): New variant of anti_dependence that
ignores the UNCHANGING_RTX_P property on memory references.
* rtl.h (unchaning_anti_dependence): Prototype here.
* flow.c (init_propagate_block): Place fake constant mem writes on
the mem_set_list so that dead writes to const variables are deleted.
(insn_dead_p): Change anti_dependence to unchanging_anti_dependence.
(mark_used_regs): Likewise.
which makes it possible for flow to delete one of the double stores in the
common cases. But it is easy to fool this mechanism (this is my example on
UltraSPARC in PR optimization/13424).
> 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.
In the ACT tree, the clearing optimization in store_constructor has been
disabled in the unsafe cases. But this means that the constness of fields
may be again a pessimization in some cases.
--
Eric Botcazou