This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 204/236] final.c: Use rtx_sequence
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Trevor Saunders <tsaunders at mozilla dot com>
- Cc: Jeff Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 15 Aug 2014 20:56:52 -0400
- Subject: Re: [PATCH 204/236] final.c: Use rtx_sequence
- Authentication-results: sourceware.org; auth=none
- References: <1407345815-14551-1-git-send-email-dmalcolm at redhat dot com> <1407345815-14551-205-git-send-email-dmalcolm at redhat dot com> <53EE88B1 dot 3090505 at redhat dot com> <20140815223848 dot GA6268 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com>
On Fri, 2014-08-15 at 18:38 -0400, Trevor Saunders wrote:
> On Fri, Aug 15, 2014 at 04:24:49PM -0600, Jeff Law wrote:
> > On 08/06/14 11:23, David Malcolm wrote:
> > >gcc/
> > > * final.c (get_attr_length_1): Replace GET_CODE check with a
> > > dyn_cast, introducing local "seq" and the use of methods of
> > > rtx_sequence.
> > > (shorten_branches): Likewise, introducing local "body_seq".
> > > Strengthen local "inner_insn" from rtx to rtx_insn *.
> > > (reemit_insn_block_notes): Replace GET_CODE check with a
> > > dyn_cast, strengthening local "body" from rtx to rtx_sequence *.
> > > Use methods of rtx_sequence.
> > > (final_scan_insn): Likewise, introducing local "seq" for when
> > > "body" is known to be a SEQUENCE, using its methods.
> > So presumably a dyn_cast isn't terribly expensive here? I guess I'm a bit
> > fuzzy on whether or not we agreed to allow using dynamic casts?!? Doesn't
> > that have to check the RTTI info which I would think would be considerably
> > more expensive than just checking the code. Or am I missing something here?
> your missing dyn_cast != dynamic_cast, the first is just a wrapper
> around as_a / is_a, and so doesn't use rtti.
Yes; as Trevor notes, this isn't using C++'s dynamic_cast and RTTI, it's
using dyn_cast from our is-a.h, so this is just:
dyn_cast (U *p)
if (is_a <T> (p))
return is_a_helper <T>::cast (p);
return static_cast <T> (0);
and (after inlining with the specializations for
T == rtx_sequence *) is essentially just:
dyn_cast (rtx p)
if (GET_CODE (p) == SEQUENCE)
return reinterpret_cast <rtx_sequence *> (p);
return static_cast <rtx_sequence *> (0);
i.e. back to just a GET_CODE check again (albeit with a new local, of
the subclass ptr type; I don't know how well our optimizations handle
that yet: the idea that a local ptr X is either equal to another local
ptr Y or is NULL. Does our value-numbering cope with this, where one
ptr is a subclass of another?).