[RFC] Issues with intraprocedural devirtualization

Hi,
this patch tries to make gimple_extract_devirt_binfo_from_cst little bit more
sane and make it match bit more cases.  Currently we seem to be able to
devirtualize only if the type in question has no basetypes (not even some not
having virtual methods at all) and it is the initial type implementing the
given virtual method (i.e. we even refuse any derivation not giving new
implementation of the virtual method in question).  This is bit silly.

What the current implemntation does

On 08/17/2013 05:44 PM, Jan Hubicka wrote:
>   1) we want the type to not have base because we may have inlined the constructor.
>      During construction the vtables are filled by base's vtable and thus we can
>      not simply devirtualize based on the final virtual table without proving that
>      constructor was not (partially) inlined.

If the constructor is inlined into the current function, then we can see 
the most recent assignment to the vptr and use that for devirtualization.

> I do not know if one can do
> something like having automatic variable of class A and use placement new
> to change it to class B.

This is something of a grey area in the standard, with a few defect 
reports yet to be resolved.  I think it should be undefined behavior.

> Finally I decided to replace the lookup of base binfo by call to
> get_binfo_at_offset.  This is not possible.  For example my base
> variable can be:
>
> struct {class A a; class B b} var;
>
> and offset 10 may point to class B.  Here I get an ICE since TYPE_BINFO
> of the structure is NULL (it is not class).

I don't understand.  In C++ a struct is a class.

> I wonder if we can track functions that return pointers/values of objects
>     exactly of given type (i.e. no derivations).

If the function returns by value, it's always a value of that exact type.

> Is the dynamic type upon return from constructor always known to be of
>     constructor's type?

Yes.

>  We may want to introduce assert_type_expr use like:
>
>     obj_ptr = assert_type_expr<class A> obj_ptr;
>
>     that can be dropped by FE for us to drive those more interesting cases, like
>     partial construction.

I guess we would need to be careful to insert those after vptr 
assignments within the constructor body, as well.

Jason

On Sat, Aug 17, 2013 at 7:56 PM, Jason Merrill <jason@redhat.com> wrote:

>> I do not know if one can do
>> something like having automatic variable of class A and use placement new
>> to change it to class B.
>
>
> This is something of a grey area in the standard, with a few defect reports
> yet to be resolved.  I think it should be undefined behavior.

Jason, could you remind me of the CWG issue numbers for these?
It is also of interest for SG12, even if it isn't going to come withe
a different answer.

-- Gaby

Jason Merrill <jason@redhat.com> wrote:
>On 08/17/2013 05:44 PM, Jan Hubicka wrote:
>>   1) we want the type to not have base because we may have inlined
>the constructor.
>>      During construction the vtables are filled by base's vtable and
>thus we can
>>      not simply devirtualize based on the final virtual table without
>proving that
>>      constructor was not (partially) inlined.
>
>If the constructor is inlined into the current function, then we can
>see 
>the most recent assignment to the vptr and use that for
>devirtualization.
>
>> I do not know if one can do
>> something like having automatic variable of class A and use placement
>new
>> to change it to class B.
>
>This is something of a grey area in the standard, with a few defect 
>reports yet to be resolved.  I think it should be undefined behavior.

I'm curious if special.casing the automatic non-pod type case is worth the trouble.  At least you need to support placement new on pod class members, in which case you need to be careful with which cases you can reliably detectat the gimple level.  As always - look at past dynamic type bugs we had with boost.

Richard.


>> Finally I decided to replace the lookup of base binfo by call to
>> get_binfo_at_offset.  This is not possible.  For example my base
>> variable can be:
>>
>> struct {class A a; class B b} var;
>>
>> and offset 10 may point to class B.  Here I get an ICE since
>TYPE_BINFO
>> of the structure is NULL (it is not class).
>
>I don't understand.  In C++ a struct is a class.
>
>> I wonder if we can track functions that return pointers/values of
>objects
>>     exactly of given type (i.e. no derivations).
>
>If the function returns by value, it's always a value of that exact
>type.
>
>> Is the dynamic type upon return from constructor always known to be
>of
>>     constructor's type?
>
>Yes.
>
>>  We may want to introduce assert_type_expr use like:
>>
>>     obj_ptr = assert_type_expr<class A> obj_ptr;
>>
>>     that can be dropped by FE for us to drive those more interesting
>cases, like
>>     partial construction.
>
>I guess we would need to be careful to insert those after vptr 
>assignments within the constructor body, as well.
>
>Jason

> On 08/17/2013 05:44 PM, Jan Hubicka wrote:
> >  1) we want the type to not have base because we may have inlined the constructor.
> >     During construction the vtables are filled by base's vtable and thus we can
> >     not simply devirtualize based on the final virtual table without proving that
> >     constructor was not (partially) inlined.
> 
> If the constructor is inlined into the current function, then we can
> see the most recent assignment to the vptr and use that for
> devirtualization.

In most cases, yes.  There are some special issues, like partial inlining
(where the "wrong" assignment gets inlined, but the final assignment not) But I
think tracking inlining those (it will need to make middle end aware of
constructors that I think is good idea anyway) and leaving those to the
constant propagation should work well enough in practice.

> 
> >I do not know if one can do
> >something like having automatic variable of class A and use placement new
> >to change it to class B.
> 
> This is something of a grey area in the standard, with a few defect
> reports yet to be resolved.  I think it should be undefined
> behavior.

I would preffer it being so ;)

> 
> >Finally I decided to replace the lookup of base binfo by call to
> >get_binfo_at_offset.  This is not possible.  For example my base
> >variable can be:
> >
> >struct {class A a; class B b} var;
> >
> >and offset 10 may point to class B.  Here I get an ICE since TYPE_BINFO
> >of the structure is NULL (it is not class).
> 
> I don't understand.  In C++ a struct is a class.

You are right.  I get the ICE here only why I handle arrays and unions, too.
(as I do in my tree, but not in the patches posted). In the example above
the struct seems to have TYPE_BINFO even though it is useless.

Since handling arrays and union seems to make sense and resolves some real
testcases from firefox, I think we could keep the tree structured in a way
making this possible.  I.e. having the type walk as proposed in the patch
instead of calling get_binfo_at_offset.
> 
> >I wonder if we can track functions that return pointers/values of objects
> >    exactly of given type (i.e. no derivations).
> 
> If the function returns by value, it's always a value of that exact type.

OK, good!
> 
> >Is the dynamic type upon return from constructor always known to be of
> >    constructor's type?
> 
> Yes.
> 
> > We may want to introduce assert_type_expr use like:
> >
> >    obj_ptr = assert_type_expr<class A> obj_ptr;
> >
> >    that can be dropped by FE for us to drive those more interesting cases, like
> >    partial construction.
> 
> I guess we would need to be careful to insert those after vptr
> assignments within the constructor body, as well.

Yes, if we go this way, we will need C++ FE to produce the asserts.

The original patch seems resonable?

Honza
> 
> Jason

> > On 08/17/2013 05:44 PM, Jan Hubicka wrote:
> > >  1) we want the type to not have base because we may have inlined the constructor.
> > >     During construction the vtables are filled by base's vtable and thus we can
> > >     not simply devirtualize based on the final virtual table without proving that
> > >     constructor was not (partially) inlined.
> > 
> > If the constructor is inlined into the current function, then we can
> > see the most recent assignment to the vptr and use that for
> > devirtualization.
> 
> In most cases, yes.  There are some special issues, like partial inlining
> (where the "wrong" assignment gets inlined, but the final assignment not) But I
> think tracking inlining those (it will need to make middle end aware of
			  ^^^^^ of constructors, partial or not.
> constructors that I think is good idea anyway) and leaving those to the
> constant propagation should work well enough in practice.

Basicaly if ctor of given type was inlined, we will make the assumption that the
type can be partially constructed.
> > >Finally I decided to replace the lookup of base binfo by call to
> > >get_binfo_at_offset.  This is not possible.  For example my base
> > >variable can be:
> > >
> > >struct {class A a; class B b} var;
> > >
> > >and offset 10 may point to class B.  Here I get an ICE since TYPE_BINFO
> > >of the structure is NULL (it is not class).
> > 
> > I don't understand.  In C++ a struct is a class.
> 
> You are right.  I get the ICE here only why I handle arrays and unions, too.
				          ^^^ when
> (as I do in my tree, but not in the patches posted). In the example above
> the struct seems to have TYPE_BINFO even though it is useless.
> 
> Since handling arrays and union seems to make sense and resolves some real
> testcases from firefox, I think we could keep the tree structured in a way
> making this possible.  I.e. having the type walk as proposed in the patch
> instead of calling get_binfo_at_offset.

Honza

Hi,
here is variant of patch that drops the field walking from
gimple_extract_devirt_binfo_from_cst completely. As pointed out
by Jason, it is pointless since all structures have BINFO in C++
and thus get_binfo_at_offset will do the job.

I would like to return the code back eventually to handle arrays&unions
but that can be done incrementally (and this is not the only place that
sufers from the problem)

Martin: I am still not quite certain about the dynamic type changing logic.
if this is the case ipa-prop needs to deal with and it handles only 0 offsets
within the outer type, I guess it can just test the offset by itself?

Honza

Bootstrapped/regtested x86_64-linux, OK?

	* ipa-cp.c (ipa_get_indirect_edge_target_1): Update use
	of gimple_extract_devirt_binfo_from_cst.
	* gimple-fold.c (gimple_extract_devirt_binfo_from_cst): Rework.
	(gimple_fold_call): Update use of gimple_extract_devirt_binfo_from_cst.
	* ipa-prop.c (try_make_edge_direct_virtual_call): Likewise.
	* gimple.h (gimple_extract_devirt_binfo_from_cst): Update.

Index: ipa-cp.c
===================================================================
*** ipa-cp.c	(revision 201814)
--- ipa-cp.c	(working copy)
*************** ipa_get_indirect_edge_target_1 (struct c
*** 1541,1554 ****
    if (TREE_CODE (t) != TREE_BINFO)
      {
        tree binfo;
        binfo = gimple_extract_devirt_binfo_from_cst
! 		 (t, ie->indirect_info->otr_type);
        if (!binfo)
  	return NULL_TREE;
!       binfo = get_binfo_at_offset (binfo, anc_offset, otr_type);
!       if (!binfo)
  	return NULL_TREE;
!       return gimple_get_virt_method_for_binfo (token, binfo);
      }
    else
      {
--- 1541,1564 ----
    if (TREE_CODE (t) != TREE_BINFO)
      {
        tree binfo;
+       tree target, base_target;
        binfo = gimple_extract_devirt_binfo_from_cst
! 		 (t, ie->indirect_info->otr_type,
! 		  ie->indirect_info->offset);
        if (!binfo)
  	return NULL_TREE;
!       target = gimple_get_virt_method_for_binfo (token, binfo);
!       if (!target)
! 	return NULL_TREE;
!       /* Constructors may be partially inlined.  We do not track
!          if type is in construction and during that time the
! 	 virtual table may correspond to virtual table of the
! 	 base type.  */
!       base_target = gimple_get_virt_method_for_binfo
! 		     (token, TYPE_BINFO (ie->indirect_info->otr_type));
!       if (base_target != target)
  	return NULL_TREE;
!       return target;
      }
    else
      {
Index: gimple-fold.c
===================================================================
*** gimple-fold.c	(revision 201814)
--- gimple-fold.c	(working copy)
*************** gimple_fold_builtin (gimple stmt)
*** 1006,1021 ****
  /* Return a binfo to be used for devirtualization of calls based on an object
     represented by a declaration (i.e. a global or automatically allocated one)
     or NULL if it cannot be found or is not safe.  CST is expected to be an
!    ADDR_EXPR of such object or the function will return NULL.  Currently it is
!    safe to use such binfo only if it has no base binfo (i.e. no ancestors)
!    EXPECTED_TYPE is type of the class virtual belongs to.  */
  
  tree
! gimple_extract_devirt_binfo_from_cst (tree cst, tree expected_type)
  {
    HOST_WIDE_INT offset, size, max_size;
!   tree base, type, binfo;
!   bool last_artificial = false;
  
    if (!flag_devirtualize
        || TREE_CODE (cst) != ADDR_EXPR
--- 1006,1025 ----
  /* Return a binfo to be used for devirtualization of calls based on an object
     represented by a declaration (i.e. a global or automatically allocated one)
     or NULL if it cannot be found or is not safe.  CST is expected to be an
!    ADDR_EXPR of such object or the function will return NULL.
! 
!    It is up to the caller to check for absence of dynamic type changes.
!    Because constructors may be partially inlined and the virtual tables
!    during construction may be overwritten by virtual tables by base types,
!    it is also up to caller to verify that either all base types have
!    the same virtual method or that this does not happen.  */
  
  tree
! gimple_extract_devirt_binfo_from_cst (tree cst, tree expected_type,
! 				      HOST_WIDE_INT otr_offset)
  {
    HOST_WIDE_INT offset, size, max_size;
!   tree base, type;
  
    if (!flag_devirtualize
        || TREE_CODE (cst) != ADDR_EXPR
*************** gimple_extract_devirt_binfo_from_cst (tr
*** 1028,1074 ****
    if (!DECL_P (base)
        || max_size == -1
        || max_size != size
!       || TREE_CODE (type) != RECORD_TYPE)
!     return NULL_TREE;
! 
!   /* Find the sub-object the constant actually refers to and mark whether it is
!      an artificial one (as opposed to a user-defined one).  */
!   while (true)
!     {
!       HOST_WIDE_INT pos, size;
!       tree fld;
! 
!       if (types_same_for_odr (type, expected_type))
! 	break;
!       if (offset < 0)
! 	return NULL_TREE;
! 
!       for (fld = TYPE_FIELDS (type); fld; fld = DECL_CHAIN (fld))
! 	{
! 	  if (TREE_CODE (fld) != FIELD_DECL)
! 	    continue;
! 
! 	  pos = int_bit_position (fld);
! 	  size = tree_low_cst (DECL_SIZE (fld), 1);
! 	  if (pos <= offset && (pos + size) > offset)
! 	    break;
! 	}
!       if (!fld || TREE_CODE (TREE_TYPE (fld)) != RECORD_TYPE)
! 	return NULL_TREE;
! 
!       last_artificial = DECL_ARTIFICIAL (fld);
!       type = TREE_TYPE (fld);
!       offset -= pos;
!     }
!   /* Artificial sub-objects are ancestors, we do not want to use them for
!      devirtualization, at least not here.  */
!   if (last_artificial)
!     return NULL_TREE;
!   binfo = TYPE_BINFO (type);
!   if (!binfo || BINFO_N_BASE_BINFOS (binfo) > 0)
      return NULL_TREE;
!   else
!     return binfo;
  }
  
  /* Attempt to fold a call statement referenced by the statement iterator GSI.
--- 1032,1042 ----
    if (!DECL_P (base)
        || max_size == -1
        || max_size != size
!       || TREE_CODE (type) != RECORD_TYPE
!       || !TYPE_BINFO (type))
      return NULL_TREE;
!   return get_binfo_at_offset (TYPE_BINFO (type),
! 			      offset + otr_offset, expected_type);
  }
  
  /* Attempt to fold a call statement referenced by the statement iterator GSI.
*************** gimple_fold_call (gimple_stmt_iterator *
*** 1108,1121 ****
        else
  	{
  	  tree obj = OBJ_TYPE_REF_OBJECT (callee);
  	  tree binfo = gimple_extract_devirt_binfo_from_cst
! 		 (obj, obj_type_ref_class (callee));
  	  if (binfo)
  	    {
  	      HOST_WIDE_INT token
  		= TREE_INT_CST_LOW (OBJ_TYPE_REF_TOKEN (callee));
  	      tree fndecl = gimple_get_virt_method_for_binfo (token, binfo);
! 	      if (fndecl)
  		{
  		  gimple_call_set_fndecl (stmt, fndecl);
  		  changed = true;
--- 1076,1095 ----
        else
  	{
  	  tree obj = OBJ_TYPE_REF_OBJECT (callee);
+ 	  tree class_type = obj_type_ref_class (callee);
  	  tree binfo = gimple_extract_devirt_binfo_from_cst
! 		 (obj, class_type, 0);
  	  if (binfo)
  	    {
  	      HOST_WIDE_INT token
  		= TREE_INT_CST_LOW (OBJ_TYPE_REF_TOKEN (callee));
  	      tree fndecl = gimple_get_virt_method_for_binfo (token, binfo);
! 	      tree base_fndecl = gimple_get_virt_method_for_binfo (token, TYPE_BINFO (class_type));
! 	      /* Constructors may be partially inlined.  We do not track
! 		 if type is in construction and during that time the
! 		 virtual table may correspond to virtual table of the
! 		 base type.  */
! 	      if (fndecl && base_fndecl == fndecl)
  		{
  		  gimple_call_set_fndecl (stmt, fndecl);
  		  changed = true;
Index: ipa-prop.c
===================================================================
*** ipa-prop.c	(revision 201814)
--- ipa-prop.c	(working copy)
*************** try_make_edge_direct_virtual_call (struc
*** 2444,2450 ****
  				   struct ipa_jump_func *jfunc,
  				   struct ipa_node_params *new_root_info)
  {
!   tree binfo, target;
  
    binfo = ipa_value_from_jfunc (new_root_info, jfunc);
  
--- 2444,2450 ----
  				   struct ipa_jump_func *jfunc,
  				   struct ipa_node_params *new_root_info)
  {
!   tree binfo, target, base_target = NULL;
  
    binfo = ipa_value_from_jfunc (new_root_info, jfunc);
  
*************** try_make_edge_direct_virtual_call (struc
*** 2454,2472 ****
    if (TREE_CODE (binfo) != TREE_BINFO)
      {
        binfo = gimple_extract_devirt_binfo_from_cst
! 		 (binfo, ie->indirect_info->otr_type);
        if (!binfo)
          return NULL;
      }
! 
!   binfo = get_binfo_at_offset (binfo, ie->indirect_info->offset,
! 			       ie->indirect_info->otr_type);
    if (binfo)
      target = gimple_get_virt_method_for_binfo (ie->indirect_info->otr_token,
  					       binfo);
    else
      return NULL;
  
    if (target)
      return ipa_make_edge_direct_to_target (ie, target);
    else
--- 2454,2484 ----
    if (TREE_CODE (binfo) != TREE_BINFO)
      {
        binfo = gimple_extract_devirt_binfo_from_cst
! 		 (binfo, ie->indirect_info->otr_type,
! 		  ie->indirect_info->offset);
        if (!binfo)
          return NULL;
+       /* Constructors may be partially inlined.  We do not track
+          if type is in construction and during that time the
+ 	 virtual table may correspond to virtual table of the
+ 	 base type.  */
+       base_target = gimple_get_virt_method_for_binfo (ie->indirect_info->otr_token,
+ 						      TYPE_BINFO (ie->indirect_info->otr_type));
+       if (!base_target)
+ 	return NULL;
      }
!   else
!     binfo = get_binfo_at_offset (binfo, ie->indirect_info->offset,
! 				 ie->indirect_info->otr_type);
    if (binfo)
      target = gimple_get_virt_method_for_binfo (ie->indirect_info->otr_token,
  					       binfo);
    else
      return NULL;
  
+   if (base_target && target != base_target)
+     return NULL;
+ 
    if (target)
      return ipa_make_edge_direct_to_target (ie, target);
    else
Index: gimple.h
===================================================================
*** gimple.h	(revision 201814)
--- gimple.h	(working copy)
*************** unsigned get_gimple_rhs_num_ops (enum tr
*** 854,860 ****
  gimple gimple_alloc_stat (enum gimple_code, unsigned MEM_STAT_DECL);
  const char *gimple_decl_printable_name (tree, int);
  tree gimple_get_virt_method_for_binfo (HOST_WIDE_INT, tree);
! tree gimple_extract_devirt_binfo_from_cst (tree, tree);
  
  /* Returns true iff T is a scalar register variable.  */
  extern bool is_gimple_reg (tree);
--- 854,860 ----
  gimple gimple_alloc_stat (enum gimple_code, unsigned MEM_STAT_DECL);
  const char *gimple_decl_printable_name (tree, int);
  tree gimple_get_virt_method_for_binfo (HOST_WIDE_INT, tree);
! tree gimple_extract_devirt_binfo_from_cst (tree, tree, HOST_WIDE_INT);
  
  /* Returns true iff T is a scalar register variable.  */
  extern bool is_gimple_reg (tree);

Hi,
I went through some statistics on firefox build (it is a source combining many coding styles).
I was basically curious where we do devirtualization.  The result is:

Before inline (i.e. important devirtualization)
    624 ssa-pre devirt 0
        this is interaprocedural devirutalization happening during early FRE by propagating
        constant accesses into vtables entries. (i.e. not type based at all)

     10 ssa-pre devirt2 0
        this is type based intraprocedural analysis during early optimizations
    177 ipa-prop devirt
	devirtualization in ipa-cp
    243 ipa-cp inline devirt
        this is devirtualization happening at IPA stage during inlining

After inline (i.e. devirtualization where we missed the chance to do something useful)
     82 gimple-fold devirt 1
	this is the gimple-fold function in question (it also run pre-inline but apparently
	always fail.  I will try the proposed patch and sed updated stats tomorrow)

     27 ipa-prop intra devirt 1
	intraprocedural type based analysis
   1569 ssa-pre devirt 1
	this is interaprocedural devirutalization happening during late FRE (not type based)

So overall type based analyssi accounts 430 devirtualizations pre-inline and 109 post inline.
Low level propagation of vtable accesses gets 624 pre-inline and 1569 post inline.

Obviously the post inline numbers shows that we miss majority of interesting cases.
I hope we can noticeably improve this.

I am re-building with the proposed change now.

Honza

> Hi,
> I went through some statistics on firefox build (it is a source combining many coding styles).
> I was basically curious where we do devirtualization.  The result is:
> 
> Before inline (i.e. important devirtualization)
>     624 ssa-pre devirt 0
>         this is interaprocedural devirutalization happening during early FRE by propagating
>         constant accesses into vtables entries. (i.e. not type based at all)
> 
>      10 ssa-pre devirt2 0
>         this is type based intraprocedural analysis during early optimizations
>     177 ipa-prop devirt
> 	devirtualization in ipa-cp
>     243 ipa-cp inline devirt
>         this is devirtualization happening at IPA stage during inlining

The promesed stats with this change.
     59 Single type devirt
	this is my new code devirtualizing types in anonymous namespaces when there is only
	one node.  I will send separate patch for this.
    696 ssa-pre devirt 0
	11% better than w/o patch (probably because of more early inline)
    537 ipa-cp inline devirt
	120% better than w/o patch
      5 ssa-pre devirt2 0
	50% less probably because I handle it earlier
    309 ipa-prop devirt
	74% more
	
     10 gimple-fold devirt2 0
	type based code in gimple-fold. It now does something.

> 
> After inline (i.e. devirtualization where we missed the chance to do something useful)
>      82 gimple-fold devirt 1
> 	this is the gimple-fold function in question (it also run pre-inline but apparently
> 	always fail.  I will try the proposed patch and sed updated stats tomorrow)
I was having trakcing bug here.  This is standard folding based propagation.
The type based path never suceeded.
> 
>      27 ipa-prop intra devirt 1
> 	intraprocedural type based analysis
>    1569 ssa-pre devirt 1
> 	this is interaprocedural devirutalization happening during late FRE (not type based)

     83 gimple-fold devirt 1
	One more.
      7 gimple-fold devirt2 1
	type based path now does something
     27 ssa-pre devirt2 1
	type based path, no change.
   1847 ssa-pre devirt 1
	17% up.
> 
> So overall type based analyssi accounts 430 devirtualizations pre-inline and 109 post inline.
> Low level propagation of vtable accesses gets 624 pre-inline and 1569 post inline.
> 
> Obviously the post inline numbers shows that we miss majority of interesting cases.
> I hope we can noticeably improve this.
> 
> I am re-building with the proposed change now.
> 
> Honza

Hi,

On Mon, Aug 19, 2013 at 11:10:31AM +0200, Jan Hubicka wrote:
> Hi,
> here is variant of patch that drops the field walking from
> gimple_extract_devirt_binfo_from_cst completely. As pointed out
> by Jason, it is pointless since all structures have BINFO in C++
> and thus get_binfo_at_offset will do the job.
> 
> I would like to return the code back eventually to handle arrays&unions
> but that can be done incrementally (and this is not the only place that
> sufers from the problem)
> 
> Martin: I am still not quite certain about the dynamic type changing logic.
> if this is the case ipa-prop needs to deal with and it handles only 0 offsets
> within the outer type, I guess it can just test the offset by itself?

In these cases, devirtualization is done according ipa invariants, no
dynamic type checks are in place, we did away with requiring the
artificial-ness of the field we devirtualize according to.
I believe your new check that the function has not been overridden is
sufficient and superior.

Thanks,

Martin

> 
> Honza
> 
> Bootstrapped/regtested x86_64-linux, OK?
> 
> 	* ipa-cp.c (ipa_get_indirect_edge_target_1): Update use
> 	of gimple_extract_devirt_binfo_from_cst.
> 	* gimple-fold.c (gimple_extract_devirt_binfo_from_cst): Rework.
> 	(gimple_fold_call): Update use of gimple_extract_devirt_binfo_from_cst.
> 	* ipa-prop.c (try_make_edge_direct_virtual_call): Likewise.
> 	* gimple.h (gimple_extract_devirt_binfo_from_cst): Update.