Steven Bosscher <[EMAIL PROTECTED]> writes: > The proposed work-around is to avoid confusing RTL alias analysis by > simply not presenting it with situations where two references to the > same memory can have different alias sets.
To recapitulate. RTL alias analysis assumes that you can reorder reads and writes through pointers which have non-conflicting alias sets (i.e., "different" alias sets). So if the same memory can be validly accessed through two different pointers, the pointers must have conflicting alias sets (i.e., the "same" alias set). RTL alias analysis is strictly type based. (I believe that the only support for non-type-based analysis is support for restricted pointers: each restricted pointer is placed in its own alias set, which is a child of the type's alias set, such that two restricted pointers of the same type do not conflict with each other.) When dealing with unions, you can take pointers to different fields in the unions. If the fields have different types, these pointers can have non-conflicting alias sets. Therefore within a single union the same memory can be read or written by different pointers. This is considered to be invalid--a valid program is required to always access the memory within the union in the same type, except if you access the memory via the union type itself (this permission being a gcc extension). If we want to permit two different objects to share the same memory location, we must ensure that we can not reorder reads and writes to the two different objects (otherwise a write to object 2 might be moved before a read from object 1). This will be true if all pointers to the two objects have conflicting alias sets. However, as we've just seen, for unions, pointers to different fields will have different alias sets. Therefore, we must in general forbid any object with union type from sharing memory with any object of any type. The only time we can permit an object with union type to share memory with an object of any other type is if we can show that a pointer to the object of non-union type will have a conflicting alias set with every pointer to every field of the union. One way to avoid this restriction would be to extend RTL alias analysis to not be strictly type based. In particular, we could extend it to know that a particular stack slot has a range of alias sets. And we would then have to know whether a particular pointer could possibly point to that stack slot. However, in general, I suspect that this would yield worse results: I suspect that we would wind up seeing alias conflicts between pointers which we do not see today, and which do not in fact conflict. Another way to avoid this restriction would be to prevent reordering of reads and writes across lexical block boundaries when objects are being shared. This would be another way of preventing the undesirable reordering of reads and writes. However, in general, I again suspect that this would yield worse results. So, I think we need to prohibit any object containing a union type from sharing a the same memory with any other object. I think that will be safe, and I think it will give us the best code overall. I'm not sure I've seen a patch to implement that draconian restriction, though perhaps I missed it. Ian
