> On 07/08/2014 02:50 PM, Jan Hubicka wrote: > >I am looking into tracking dynamic types now. Obviously I need to set very > >exact rules about when these may change. > > Let me first say that this area is somewhat in flux in the standard; > if we have a model of what we want the rules to be for GCC, there's > a good chance of getting them into the standard. There are several > unresolved DRs in this area already (1027, 1116, 1776). > > >I think b variants are invalid > > Yes, by 3.8/7; we can't use 'a' to call foo after we've changed the > object there to a C. > > >currently we also assume t1 to be invalid, but > >t2 to be valid. > > I think the compiler ought to be able to treat both as undefined, > because 'a' is either defined (t1) or allocated (t2) as a B, and B > does not contain an array of char, so changing the dynamic type of > that memory before the end of its storage duration ought to be > undefined. > > But the standard doesn't currently say that, though it's along the > lines of my proposed drafting for 1116 (which needs reworking). > > And I suppose that my notion of 'allocated type' can really only > apply when using the library allocation functions in 18.6.1.1 and > 18.6.1.2, not the inline placement new.
Thanks! I guess we will have chance to chat about this on the Cauldron? As you probably know, for middle-end analysis it would be good if types was as sticky as possible. The sucess of type based devirtualization is largely based on the fact that it is hard to track a value of memory location by alias analysis (as calls to external functions are generally believed to change it) but it is easier to track type of a memory location, because the ways it can change are limited to construcition/destruction and placement news. I really only care about types containing virtual table pointers to not change, so non-PODs are out of game. Current propagation is built around assumption that once polymorphic type is constructed on a given location it won't change to completely different type, only possibly repatively construct & destruct. This is based on our arlier conversation where the outcome was that chaning non-POD variable by placement new to different type is not defined. Anything weakter will probably need some cooperation from the frontend - I suppose best tie we have is the fact that you can't use 'a' to call foo after changing object. If placement news was marked for some time by a builtin, we could effectively thread the re-allocated objects as a new memory locations.. So perhaps we can go with my dynamic type patch enforcing the strong interpretation (no changes beyond construction/destruction once polymorphic type lands on a given location) and document it (do we have convenient place in the user documentation). If it turns out to be impractical, we can always carefuly relax it? Where I find current wording of DR1116? Honza > > Jason
