This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: GCC Status Report (2004-03-09)


    > Can't we at least detect the case where either the whole aggregate
    > is const or all its fields are const?  Then we don't need any blockage.

    So we endorse the double /u liberality?

I don't.

As I said in more private email, my feeling in the /u case where you have
a partial aggregate is to do the stores into a temporary and move it into
the /u.  Yes, that's less efficient and in many ways more than undoes the
advantage of /u, but partial aggregates are rare.

I think that's cleaner than blockage stuff.

I don't know what to think about /u overall.  It's becoming more and more
clear that it's the source of a lot of trouble and probably is becoming
less and less useful with aliasing code around anyway.  I'd be in favor
of trying the experiment of only using it on data that's *never* explicitly
stored (like constant-pool or items with static initializers).  So we
disallow stores to /u.


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