This is the mail archive of the 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: rtx_unchanging_p vs c++ vtable fields

    You're missing the whole point.  The field should not be marked
    unchanging because it is stored multiple times.  But it did get
    marked unchanging, and that is the reason the test fails.

Just to make sure we mean the same thing, I mean TREE_READONLY on the

    That is false.  There is *no* "always safe" direction.

    If a store is marked unchanging, then it will be considered
    to conflict with no other stores.  And when that happens, the
    stores can get swapped by the scheduler.

Hmm.  That's a problem.  Consider a record with two fields, one of which ais
reaadonly and one of which is not.  Suppose we have reads of the individual
fields and a write of the whole record (e.g.: each field is HImode and the
record is SImode).  One of those reads will be /u and the other will not have
/u.  Should the write have /u or not?  If it doesn't, then it will not be
considered as conflicting with the read of the unchanging field, which is
wrong, but if it doesn't, then you have the problem you just mention.  I'm
not sure what the best approach is here.  I think we may well have to ignore
/u when seeing if two stores conflict.

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