[Bug c++/115410] New: Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[Bug c++/115410] New: Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[user202729 at protonmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410

            Bug ID: 115410
           Summary: Missing optimization: typeid(*a)==typeid(*b) could be
                    optimized to a->_vptr==b->_vptr
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: user202729 at protonmail dot com
  Target Milestone: ---

As in the title. I think if both `*a` and `*b` are objects of type with a
virtual pointer then `typeid(*a)==typeid(*b)` could be optimized to

    if(!a) throw bad_typeid;
    if(!b) throw bad_typeid;
    return a->_vptr==b->_vptr;

Godbolt: https://godbolt.org/z/MjY67Pc4b

Although I think this optimization should be done at the level of the C++ front
end (`cp_build_binary_op`?) because once the expression is down to gimple level
then it becomes something like

    type_info::operator==(a->_vptr[-1], b->vptr[-1])

and it seems not clean to hard code the constant `-1` (it is currently hard
coded only in `get_tinfo_decl_dynamic` function).

[Bug c++/115410] Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am not so sure. Many times the comparison becomes a string comparison and not
comparing the vtable.

[Bug c++/115410] Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[user202729 at protonmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410

--- Comment #2 from user202729 <user202729 at protonmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> I am not so sure. Many times the comparison becomes a string comparison and
> not comparing the vtable.

That's my point. Pointer comparison is faster than string comparison, and it
should hold that the typeid are equal iff the types are equal iff the vptr are
equal, so the optimization should be valid.

[Bug c++/115410] Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Except it is not valid. 

See https://gcc.gnu.org/pipermail/libstdc++/2004-February/021443.html which
changed this to be always a string comparison.

[Bug c++/115410] Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
From the header:
Even with the new abi, on systems that support dlopen
    // we can run into cases where type_info names aren't merged,
    // so we still need to do string comparison

[Bug c++/115410] Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[user202729 at protonmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410

--- Comment #5 from user202729 <user202729 at protonmail dot com> ---
(In reply to Andrew Pinski from comment #3)
> Except it is not valid. 
> 
> See https://gcc.gnu.org/pipermail/libstdc++/2004-February/021443.html which
> changed this to be always a string comparison.

Thanks for informing me.

However, that comment talks about `type_info` names aren't merged (i.e. it's
possible for the `__name` pointers to be different but their contents are the
same), but is it possible for the virtual table address to be different for the
same type?

(I don't think it's possible because virtual table becomes linker symbols?)

[Bug c++/115410] Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
They can be different due to the way shared libraries work.

[Bug c++/115410] Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[user202729 at protonmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410

--- Comment #7 from user202729 <user202729 at protonmail dot com> ---
(In reply to Andrew Pinski from comment #6)
> They can be different due to the way shared libraries work.

Ah, too bad.

Is it safe to at least assume that the function pointers inside the virtual
pointer table be equal then? The original motivation was to devirtualize the
function call inside something like (though this would be a different PR)

    if(typeid(*x)==typeid(A))
        x->f();

then would it be safe to assume `x->_vptr[0] == &A::f`?

[Bug c++/115410] Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to user202729 from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > They can be different due to the way shared libraries work.
> 
> Ah, too bad.
> 
> Is it safe to at least assume that the function pointers inside the virtual
> pointer table be equal then?

No, there can be multiple definitions of a symbol, with different addresses.


 The original motivation was to devirtualize the
> function call inside something like (though this would be a different PR)
> 
>     if(typeid(*x)==typeid(A))
>         x->f();
> 
> then would it be safe to assume `x->_vptr[0] == &A::f`?

No, but the transformation might be valid anyway. There could be multiple
copies of A::f with different addresses, but they all have to have the same
effects and so it doesn't matter which one gets called.

[Bug c++/115410] Missing optimization: typeid(*a)==typeid(*b) could be optimized to a->_vptr==b->_vptr

[user202729 at protonmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410

--- Comment #9 from user202729 <user202729 at protonmail dot com> ---
Alright, I open https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413 instead
(discussing one case where gcc already calls a different function from what it
should)