C++ and gather-detailed-mem-stats

[Richard Guenther <rguenther at suse dot de>]

I face an issue with replacing macros with C++ functions and the
way we implement gather-detailed-mem-stats.  Currently the
mem-stat info is passed at the call site of functions via macros
like

#define VEC_safe_grow_cleared(T,A,V,I)                  \
        (VEC_safe_grow_cleared_1<T,A> (&(V), (int)(I)   \
                                       VEC_CHECK_INFO MEM_STAT_INFO))

that dispatch to

template<typename T, enum vec_allocation_t A>
static inline void
VEC_safe_grow_cleared_1 (vec_t<T> **vec_, int size_ VEC_CHECK_DECL
                         MEM_STAT_DECL)
{
  int oldsize = VEC_length (T, *vec_);
  VEC_safe_grow_1<T, A> (vec_, size_ VEC_CHECK_PASS PASS_MEM_STAT);
  memset (&(VEC_address (T, *vec_)[oldsize]), 0,
          sizeof (T) * (size_ - oldsize));
}

which will then collect statistics about the caller site of
VEC_safe_grow_cleared_1.

Now trying to convert gimple_build_assign_with_ops3 to an overloaded
function, and thus converting gimple_build_assign_with_ops from a
macro to a function results in

*************** gimple gimple_build_assign_stat (tree, t
*** 744,755 ****

  void extract_ops_from_tree_1 (tree, enum tree_code *, tree *, tree *, 
tree *);

  gimple gimple_build_assign_with_ops_stat (enum tree_code, tree, tree,
                                          tree, tree MEM_STAT_DECL);
! #define gimple_build_assign_with_ops(c,o1,o2,o3)                      \
!   gimple_build_assign_with_ops_stat (c, o1, o2, o3, NULL_TREE 
MEM_STAT_INFO)
! #define gimple_build_assign_with_ops3(c,o1,o2,o3,o4)                  \
!   gimple_build_assign_with_ops_stat (c, o1, o2, o3, o4 MEM_STAT_INFO)

  gimple gimple_build_debug_bind_stat (tree, tree, gimple MEM_STAT_DECL);
  #define gimple_build_debug_bind(var,val,stmt)                 \
--- 744,774 ----

  void extract_ops_from_tree_1 (tree, enum tree_code *, tree *, tree *, 
tree *);

+ inline enum gimple_rhs_class get_gimple_rhs_class (enum tree_code);
  gimple gimple_build_assign_with_ops_stat (enum tree_code, tree, tree,
                                          tree, tree MEM_STAT_DECL);
!
! inline gimple
! gimple_build_assign_with_ops (enum tree_code code, tree lhs,
!                             tree op1, tree op2)
! {
!   return gimple_build_assign_with_ops_stat (code, lhs,
!                                           op1, op2, NULL_TREE 
MEM_STAT_INFO);
! }
!
! /* Build and return a GIMPLE assignment statement assigning CODE applied
!    to OP1, OP2 and OP3 to LHS.
!    CODE, OP1, OP2 and OP3 should be appropriate for a GIMPLE_TERNARY_RHS
!    assign.  */
!
! inline gimple
! gimple_build_assign_with_ops (enum tree_code code, tree lhs,
!                             tree op1, tree op2, tree op3)
! {
!   gcc_checking_assert (get_gimple_rhs_class (code) == 
GIMPLE_TERNARY_RHS);
!   return gimple_build_assign_with_ops_stat (code, lhs,
!                                           op1, op2, op3 MEM_STAT_INFO);
! }

  gimple gimple_build_debug_bind_stat (tree, tree, gimple MEM_STAT_DECL);
  #define gimple_build_debug_bind(var,val,stmt)                 \

but that will now account all gimple_build_assign_with_ops_stat calls
to the gimple_build_assign_with_ops function overloads instead of
to its caller.  I don't see how we can preserve this functionality
with C++ short of requiring user code to tack on MEM_STAT_INFO
on all calls?  At least (obviously) default arguments like

void foo (int bla, const char *file = __FILE__, int line = __LINE__,
          const char *function = __FUNCTION__);

will not work.

Losing the detailed memory stats would be very bad and sticking
with macros everywhere (and thus making function overloading impossible
for memory tracked functionality) is bad.

Any insights from people with enough C++ fu?  The 
gather-detailed-mem-stats feature may depend on GCC, thus a language
extension ("delayed" __FILE__ / __LINE__ / __FUNCTION__, a function
attribute that directs the frontend to attach more arguments at a
call site, etc.) would be permitted.  But is C++ really that "bad"?

Thanks,
Richard.