Re: Change to readonly conflict handling

[Geoff Keating <geoffk at cygnus dot com>]

> Date: Sun, 17 Sep 00 20:30:50 EDT
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> Cc: gcc@gcc.gnu.org
> 
>     This code is actually not valid C; neither of the two assignments are
>     valid, because they change p->a and q->a which are 'const'.  
> 
> Yes, I know, but I don't think there's any way to get it from valid C.  This
> was meant to be as close I could get the actual case, which was from Ada.
> 
>     Actually, what I get is _both_ words of *p and *q being stored with
>     /u.  On powerpc (so the fields are SImode):
> 
> Right, I get that too.  I even think I see why, though it is a bug.
> 
> 
> (insn 16 15 19 (set (mem/s/u:DI (reg/v:SI 82) 0)
>         (reg:DI 86)) -1 (nil)
>     (nil))
> 
> (insn 19 16 20 (set (reg:DI 87)
>         (mem/s:DI (reg/v:SI 82) 0)) -1 (nil)
>     (nil))
> 
> But *this* is key: it's being stored *with* the "/u", but loaded without.
> That will cause these two loads to be marked non-conflicting, which may
> have them scheduled in the wrong order (how I ran into the bug).

Yes, but see:  it's not the field itself that is being stored or read
readonly, it's the whole structure.  Yet the structure is not readonly.

> Oh, I see why they are both readonly.  The readonly_fields_p logic sets
> the whole thing readonly and we don't ever turn it off once the actual
> target gets it set.  Perhaps a bug, but I'm not sure how else to do this.

I'd just decide that RTX_UNCHANGING_P is not the construct that should
be used to represent constant fields.

-- 
- Geoffrey Keating <geoffk@cygnus.com>