This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 204/236] final.c: Use rtx_sequence


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:

inline T
dyn_cast (U *p)
{
  if (is_a <T> (p))
    return is_a_helper <T>::cast (p);
  else
    return static_cast <T> (0);
}

and (after inlining with the specializations for
T == rtx_sequence *) is essentially just:

rtx_sequence *
dyn_cast (rtx p)
{
  if (GET_CODE (p) == SEQUENCE)
    return reinterpret_cast <rtx_sequence *> (p);
  else
    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?).

Dave


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]