This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix PR58477, part II
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 19 Dec 2013 17:31:24 +0100
- Subject: Re: Fix PR58477, part II
- Authentication-results: sourceware.org; auth=none
- References: <20131214220153 dot GA18087 at kam dot mff dot cuni dot cz> <20131216134524 dot GF25652 at virgil dot suse> <20131216135811 dot GA6626 at kam dot mff dot cuni dot cz> <CAFiYyc3Vyy8ERQhn38ZhQE8=PrBQCH9Bj+hTY_+3quHrYJvqMg at mail dot gmail dot com> <20131218123952 dot GB16572 at kam dot mff dot cuni dot cz>
On Wed, Dec 18, 2013 at 1:39 PM, Jan Hubicka <hubicka@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