Re: TCB merge: VRP, copy propagation, store copy propagation andstore CCP

[Paul Schlie <schlie at comcast dot net>]

> Diego Novillo <dnovillo at redhat dot com>
> - Never consider global read-only variables to be clobbered by
>  any kind of store operation.
>  http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01252.html
>
>  This has caused grief in SPEC2000's eon because the C++ FE is
>  emitting stores to read-only global variables, so I have
>  disabled the transformation for V_MUST_DEF operands for now.
>
>  This was also causing massive slowdowns with the new immediate
>  uses code because we were generating immuse lists that were
>  about 7 times longer than before.  Andrew kindly fixed this for
>  me earlier this week, so the slowdowns are gone now.

Out of curiosity (or rather necessity) as I'm relying on identifying
declared "static const" objects and initializing literal memory value
references as being identifiable by MEM_READONLY_P (i.e. unchanging)
at the tree/rtl level, so that a target may designate such data as being
accessed directly from ROM, which may correspondingly require different
load instructions to access, vs. copying them unnecessarily into RAM
consuming potentially valuable memory space upon program initialization
as an embedded target optimization;  do you have any insight when C++'s
FE improper "static const" variable designation problem may be fixed?

As it would seem that true "static const" objects should never need to be
designated as being written to by the FE, although the objects which they
may initialize obviously would need to be (which by definition aren't
truly "static const" objects, although may be "const" objects), as "static
const" objects never need to be "allocated or correspondingly initialized"
during program execution, as "static const" objects should only be accessed
by static reference regardless of where they may have been designated as
being statically stored prior to program execution; it would seem?