This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Your June 7 change to expand_expr
- To: mark at markmitchell dot com
- Subject: Re: Your June 7 change to expand_expr
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 01 Jul 1998 01:03:24 -0600
- cc: kenner at vlsi1 dot ultra dot nyu dot edu, egcs-bugs at cygnus dot com, jfc at mit dot edu, wilson at cygnus dot com
- Reply-To: law at cygnus dot com
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