This is the mail archive of the
mailing list for the GCC project.
Re: rtx_unchanging_p vs c++ vtable fields
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rth at redhat dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 9 Dec 01 16:17:33 EST
- Subject: 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.