Re: Internal macros as fns for debug

[Doug Landauer <landauer at apple dot com>]

> Have you (or anybody else) started doing this, at least for
> rtl-accessors?

I did something like this for most of the RTL and TREE accessors,
though in a somewhat more awkward way (I didn't realize that
surrounding the macro name in parens would prevent its expansion).


Is there a macro gcc developers use to mean "WHILE_DEBUGGING_GCC",
that these things could be #ifdef'd under?


I could send you what I have, if you're interested.  I've included
some excerpts, below.

> Sketches:
> - Prototypes in rtl.h
> - Functions in (new) internal-debug.c (or keep them in rtl.c?)

I'd say put them in a new file -- I find the TREE ones
vital to my debugging work, during those times that our gdb is
healthy enough to understand them.



> - Functions and declaration guarded by autoconf macro
>   (HAVE_MACRONAME_AS_IDENTIFIER) for the benefit of bootstrapping
>   from broken preprocessors that don't like the same token as macro
>   and identifier token - if there are any.

Perhaps my method could be used for some of those preprocessors,
although it does depend on "##" working.

 
> Anyway, Merry Christmas and Happy Holidays to you all.

And you.


Here are some of the TREE macros ...

/* TREE and RTL debugging macro functions.  What we do here is to
  instantiate each macro as a function *BY THE SAME NAME*.  Depends
  on having the '##' macro operator to paste together a name x_MACRO,
  then we define that function to call the (expanded) macro, then we
  '#undef' the MACRO, and finally define another function, named
  MACRO, to call the x_MACRO function.

  Note that the fact that we #undef the thing doesn't matter even
  if later macros need that macro:  those uses will just turn into
  function calls instead of macros!   */

#define pre_1_fn( m, rt, pt ) \
    rt x_ ## m ( pt a ) {     \
     return  m(a) ;           \
    }

#define post_1_fn( m, rt, pt ) \
    rt m ( pt a ) {            \
     return  x_ ## m (a) ;     \
    }

#define pre_2_fn( m, rt, p1, p2 ) \
    rt x_ ## m ( p1 a, p2 b ) {   \
     return  m(a,b) ;             \
    }

#define post_2_fn( m, rt, p1, p2 ) \
    rt m ( p1 a, p2 b ) {          \
     return  x_ ## m (a, b) ;      \
    }

#include "rtl.h"

/* MACROS from tree.h (single-parameter ones) */

pre_1_fn( AGGREGATE_TYPE_P, int, tree )
#undef AGGREGATE_TYPE_P
post_1_fn( AGGREGATE_TYPE_P, int, tree )

pre_1_fn( BINFO_BASETYPES, tree, tree )
#undef BINFO_BASETYPES
post_1_fn( BINFO_BASETYPES, tree, tree )

pre_1_fn( BINFO_INHERITANCE_CHAIN, tree, tree )
#undef BINFO_INHERITANCE_CHAIN
post_1_fn( BINFO_INHERITANCE_CHAIN, tree, tree )

pre_1_fn( BINFO_OFFSET, tree, tree )
#undef BINFO_OFFSET
post_1_fn( BINFO_OFFSET, tree, tree )

pre_1_fn( BINFO_OFFSET_ZEROP, int, tree )
#undef BINFO_OFFSET_ZEROP
post_1_fn( BINFO_OFFSET_ZEROP, int, tree )

pre_1_fn( BINFO_SIZE, tree, tree )
#undef BINFO_SIZE
post_1_fn( BINFO_SIZE, tree, tree )

pre_1_fn( BINFO_TYPE, tree, tree )
#undef BINFO_TYPE
post_1_fn( BINFO_TYPE, tree, tree )

pre_1_fn( BINFO_VIRTUALS, tree, tree )
#undef BINFO_VIRTUALS
post_1_fn( BINFO_VIRTUALS, tree, tree )

  ...  and lots more ...




/* MACROS from rtl.h (single-parameter ones):
   MACRO_NAME, returnType, param,
       almost always rtx, rtx */

pre_1_fn( ADDR_DIFF_VEC_FLAGS, addr_diff_vec_flags, rtx )
#undef ADDR_DIFF_VEC_FLAGS
post_1_fn( ADDR_DIFF_VEC_FLAGS, addr_diff_vec_flags, rtx )

pre_1_fn( ADDRESSOF_DECL, tree, rtx )
#undef ADDRESSOF_DECL
post_1_fn( ADDRESSOF_DECL, tree, rtx )

pre_1_fn( ADDRESSOF_REGNO, int, rtx )
#undef ADDRESSOF_REGNO
post_1_fn( ADDRESSOF_REGNO, int, rtx )

pre_1_fn( CALL_INSN_FUNCTION_USAGE, rtx, rtx )
#undef CALL_INSN_FUNCTION_USAGE
post_1_fn( CALL_INSN_FUNCTION_USAGE, rtx, rtx )

pre_1_fn( CODE_LABEL_NUMBER, int, rtx )
#undef CODE_LABEL_NUMBER
post_1_fn( CODE_LABEL_NUMBER, int, rtx )

pre_1_fn( CONST0_RTX, rtx, rtx )
#undef CONST0_RTX
post_1_fn( CONST0_RTX, rtx, rtx )


   ... and many many more ...

  and there are quite a few from cp/ptree.h as well.

Total for my method is about 2800 lines of code.  You can probably
take them and work them over with emacs or python or something to turn
them into your cleaner method of function definitions.


    -- Doug Landauer