Your June 7 change to expand_expr

[Jeffrey A Law]

  In message < 199807010621.XAA28094@smtp.earthlink.net >you write:
  >     Jeffrey> It's also likely we could use the tri-state to fix
  >     Jeffrey> 980506-2.c (jfc's testcase where cse changes
  >     Jeffrey> MEM_IN_STRUCT_P in an unsafe manner).  We might want to
  >     Jeffrey> do the tri-state regardless of the final outcome of
  >     Jeffrey> Kenner's patch & your failing code since it provides us
  >     Jeffrey> with a "safe state" that we can use when it's not clear
  >     Jeffrey> if a MEM should have the bit set.
  > 
  > Yes.  The more I think about this, the more I think that if we keep
  > MEM_IN_STRUCT_P we must make a tri-state thing.
It ought to be pretty easy.

I think we allocate another flag bit, initialize it to zero, and set
it to one when we don't know if MEM_IN_STRUCT_P is "valid".

We have the alias code check the new bit to make sure MEM_IN_STRUCT_P
is valid before making any use of MEM_IN_STRUCT_P.  We should also
look at other places that look at MEM_IN_STRUCT_P.

alias.c, cse.c, explow.c, genattrtab.c (?), loop.c, all appear to
look at the value instead of just copying it around.

What to call the new bit?  MEM_IN_STRUCT_P_VALID_P? (Yuck).  

Or do we make a real tri-state out of two bits so that we can encode
an additional state? (in_struct, !in_struct, unknown, ? other use?)


jeff