> Eric Botcazou writes:
>> Jeffrey A Law writes:
>> ...
>> Which faults because the memory location is actually read-only memory.
>
> PR rtl-optimization/15248.
>
>> What's not clear to me is how best to fix this.
>>
>> We could try to delete all assignments to pseudos which are equivalent
>> to MEMs.
>>
>> We could avoid recording equivalences when the pseudo is set more than
>> once.
>>
>> Other possibilities?
>
> For 3.3 and 3.4, this was "fixed" by not recording memory equivalences that
> have the infamous RTX_UNCHANGING_P flag set.
As my understanding is that UNCHANGING is/should-be uniquely associated
with "literal static const data", which may have been declared either via
an explicit "static const" variable declaration, or indirectly as a literal
const value which may be used to initialize non-"static const" variable
values; and who's reference may not survive if all uses of it's declared
value are in-lined as immediate data.
As such all other uses of "UNCHANGING" potentially denoting const variables
are incorrect, and should be fixed; as "const" need not exist in tree data
to denote constant variables, as the trees should already be "correct by
construction", as the language's "front-end" should have prevented any
assignments to declared "const" variables other than initialization from
being constructed. Thereby as none of the optimizations should modify the
semantics of the tree, a const variable will never be assigned a logical
value other than it's designated initializer value, which may either be
spilled and reloaded as any other variable's value may be, or regenerated
by reallocating and reinitializing it if preferred. (Correspondingly all
tree/rtx optimizations which convert a (mem (symb)) => (mem (ptr))
reference must copy/preserve the original mem reference attributes to the
new one, as otherwise they will be improperly lost.)
Thereby MEM_READONLY_P uniquely applies to "literal static const data"
references to enable it's allocation and accesses to be reliably
identifiable as may be required to enable target specific "literal static
const data" allocation and code generation, as may be required if stored
and accessed from a target specific ROM memory region.
i.e.:
static const char s[] = "abc"; // s[4] = {'a','b','c',0} array
// of "literal static const data"
// MEM_READONLY_P (mem(symb(s))) == true;
static char s[] = "abc"; // "C.x[4] = {'a','b','c',0} array
// of "literal static const data"
// MEM_READONLY_P (mem(symb(C.x))) == true;
// s[4] array of char, init with C.x[]
// MEM_READONLY_P (mem(symb(s))) == false;
const char s[] = "abc"; // "C.x[4] = {'a','b','c',0} array
// of "literal static const data"
// MEM_READONLY_P (mem(symb(C.x))) == true;
// s[4] array of char, init with C.x[]
// MEM_READONLY_P (mem(symb(s))) == false;
some-const-char*-funct("abc"); // "C.x[4] = {'a','b','c',0} array
// of "literal static const data"
// some-const-char*-funct(C.x);
(Does that seem correct?)
