This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Your June 7 change to expand_expr


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]