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: law at cygnus dot com
- Subject: Re: Your June 7 change to expand_expr
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Tue, 30 Jun 1998 23:21:43 -0700
- 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
- References: <20301.899272905@hurl.cygnus.com>
- Reply-to: mark at markmitchell dot com
>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:
Jeffrey> In message
Jeffrey> <199807010547.WAA27889@smtp.earthlink.net>you write:
>> >>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:
>>
>> One option is to make MEM_IN_STRUCT_P ternary (yes: definitely
>> in struct, no: definitely not in struct, and don't know).
>> Then, as Kenner points out would be desirable, we would have a
>> conservative setting, and yet we could still do the
>> fixed/varying struct/not-struct optimization.
Jeffrey> I think this or a variant thereof is probably the best
Jeffrey> solution unless, we fell that our alias code is good
Jeffrey> enough now to ignore MEM_IN_STRUCT_P totally. I suspect
Jeffrey> it isn't, but I don't have any hard data to back that up.
I think that the struct/varying bit is an optimization that we can't,
as of yet, get any other way.
Jeffrey> The other possibility is that Kenner's change is simply
Jeffrey> incorrect and papering over a problem elsewhere -- or
Jeffrey> that the code that's failing for you is doing something
Jeffrey> unsafe. We're looking into the former, but I don't think
Jeffrey> we've looked into the latter yet.
Actually, I have. It's fine. It's only supporting evidence, but the
code ompiles and works fine with other rather agressive optimizers,
such as KCC and the SGI MIPS compilers. The code has been is use for
a long time. (I know none of that is too impressive; you'll have to
take my word that the code is OK based on my inspection of it, I
guess.)
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.
Jeffrey> jeff
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com