On Wed, Dec 18, 2013 at 1:39 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> > OK, so the explanation is not as simple as claim that non-POD types >> > needs to be constructed or copied by constructor and C++ FE always >> > generate an explicit vtbl store? >> >> No as optimizers may combine stores for example. > > Yep, I understand we can design "evil" optimization that will make problem > of tracking virtual table pointers very hard. > The question is how much we want to have these pre-IPA and how their benefits > relate to beenfits from improved devirtualization.
Well, if devirt relies on code appearing in a very special way and only in that way then it is broken. devirt, as any other transform, has to work conservative correctly. As a way out you can define a unique way how vtable pointer init has to work and that other passes don't mess with (because they don't know it). For example add a no-op handled component VTBL_REF (or not no-op and encode an offset with it). > We are still weak on deivrt (and current generation benchmarks don't seem to > care much on how good we are), so at the moment my approach is to improve the > analysis without imposing additional restriction. but in longer turn we may > want to make some compromises (pre-ipa) here and preserve more information in > gimple. At the moment GIMPLE doesn't know about vtable pointers or the vtable slot. You'd have to teach it in some way and at some point lower. Richard. > Honza >> >> >> Of course, having gimple defined and required annotation for vptr >> >> changes would be much better but then of course all transformations >> >> would have to make sure they preserve it. >> >> >> >> IIRC, flag_strict_aliasing test was explicitely Richard's request, >> >> perhaps we could restrict the pointer type test further. >> >> >> >> Does that answer your question? >> > >> > Sort of, yes. We should make some analysis how effective current >> > methods are (i.e. disabling it and checking how much devirtualization >> > improve for firefox) and if we find they seem insufficient, we probably >> > should think of better analysis or annotation... >> > >> > Honza
