On 9/16/21 22:29, Feng Xue OS wrote:
On 9/16/21 05:25, Feng Xue OS via Gcc-patches wrote:
This and following patches are composed to enable full devirtualization
under whole program assumption (so also called whole-program
devirtualization, WPD for short), which is an enhancement to current
speculative devirtualization. The base of the optimization is how to
identify class type that is local in terms of whole-program scope, at
least those class types in libstdc++ must be excluded in some way.
Our means is to use typeinfo symbol as identity marker of a class since
it is unique and always generated once the class or its derived type
is instantiated somewhere, and rely on symbol resolution by
lto-linker-plugin to detect whether a typeinfo is referenced by regular
object/library, which indirectly tells class types are escaped or not.
The RFC at https://gcc.gnu.org/pipermail/gcc/2021-August/237132.html
gives more details on that.
Bootstrapped/regtested on x86_64-linux and aarch64-linux.
Thanks,
Feng
----
2021-09-07 Feng Xue <f...@os.amperecomputing.com>
gcc/
* common.opt (-fdevirtualize-fully): New option.
* class.c (build_rtti_vtbl_entries): Force generation of typeinfo
even -fno-rtti is specificied under full devirtualization.
This makes -fno-rtti useless; rather than this, you should warn about
the combination of flags and force flag_rtti on. It also sounds like
you depend on the library not being built with -fno-rtti.
Although rtti is generated by front-end, we will remove it after lto symtab
merge, which is meant to keep same behavior as -fno-rtti.
Ah, the cp/ change is OK, then, with a comment about that.
Yes, regular library to be linked with should contain rtti data, otherwise
WPD could not deduce class type usage safely. By default, we can think
that it should work for libstdc++, but it probably becomes a problem for
user library, which might be avoided if we properly document this
requirement and suggest user doing that when using WPD.
Yes, I would expect that external libraries would be built with RTTI on
to allow users to use RTTI features even if they aren't used within the
library. But it's good to document it as a requirement.
+ /* If a class with virtual base is only instantiated as
+ subobjects of derived classes, and has no complete object in
+ compilation unit, merely construction vtables will be involved,
+ its primary vtable is really not needed, and subject to being
+ removed. So once a vtable node is encountered, for all
+ polymorphic base classes of the vtable's context class, always
+ force generation of primary vtable nodes when full
+ devirtualization is enabled. */
Why do you need the primary vtable if you're relying on RTTI info?
Construction vtables will point to the same RTTI node.
+ /* Public class w/o key member function (or local class in a public
+ inline function) requires COMDAT-like vtable so as to be shared
+ among units. But C++ privatizing via -fno-weak would introduce
+ multiple static vtable copies for one class in merged lto symbol
+ table. This breaks one-to-one correspondence between class and
+ vtable, and makes class liveness check become not that easy. To
+ be simple, we exclude such kind of class from our choice list.
Same question. Also, why would you use -fno-weak? Forcing multiple
copies of things we're perfectly capable of combining seems like a
strange choice. You can privatize things with the symbol visibility
controls or RTLD_LOCAL.
Jason
