Re: [PATCH 0/6] Convert gimple to a C++ class hierarchy

[Michael Matz <matz at suse dot de>]

Hi,

On Fri, 30 Aug 2013, David Malcolm wrote:

> Here's the result of a pair of builds of r202029 without and with the
> patches, configured with --enable-checking=release, running "make", then
> stripping debuginfo [1]
> 
> So the overall sizes of such binaries are essentially unchanged.

Yep, cool.

> Any suggestions on what to compile to compare performance?  By 60 
> seconds, do you mean 60s for one TU, or do you mean a large build e.g. 
> the linux kernel?

For one TU, so as to not measure any significant execve, as or IO 
overhead.  Some people compile e.g preprocessed variants of some GCC 
source file, myself I'm measuring such speeds since some years with 
unchanged versions of the attached (big-code.c, several large functions 
with arithmetics and one-deep loops) which can be customized 
by hand to produce different largeness and kdecore.cc [1] (real world C++ 
library code from 2009).

You can customize big-code.c to match some compile time goal by 
commenting out some FUNC invocation for some types, or by changing the 
body size of the functions by fiddling in the FUNC macro itself to invoke 
more of the L2's or even L3's, but that's really slow.

> > And the manual GTY markers are so not maintainable in the long run, 
> > gengtype or something else really needs to be taught to create them 
> > automatically.
> 
> Apart from the GTY aspect, how do people feel about the patch series?

Generally I like it, the parts I don't like are common to all the 
C++ification patches [2].  The manual GTY parts give me the creeps, but I 
think I expressed that already :)


Ciao,
Michael.
[1] http://frakked.de/~matz/kdecore.cc.gz 
[2] In this series it's the is_a/has_a/dyn_cast uglification,
    -  gcc_gimple_checking_assert (gimple_has_mem_ops (g));
    -  g->gsmembase.vuse = vuse;
    +  gimple_statement_with_memory_ops *mem_ops_stmt =
    +    as_a <gimple_statement_with_memory_ops> (g);
    +  mem_ops_stmt->vuse = vuse;

    I can't really say I find this shorter, easier to read, more
    expressive or even safer than what was there before.  And the 
    repetition for adding the helpers for const and non-const types
    all the time doesn't make it better.

    (Btw: something for your helper script: it's customary to put the
    '=' to the next line; I know there is precedent for your variant,
    but '=' on next line is prevalent)

extern int get_i(void);
typedef signed char schar;
typedef unsigned char uchar;
typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
typedef long long llong;
typedef unsigned long long ullong;
typedef long double ldouble;

#define BODY(T) \
for (i = get_i(); i; i--) { \
  accum += do_1_ ## T(accum, x, y, z); \
  switch (get_i()) { \
    case 1: case 3: case 34: case 123: \
      if (z*x > y) \
        x = do_2_ ## T (x * y + z); \
      else \
        y = do_3_ ## T (x / y - z); \
      break; \
    case 6: case 43: case -2: \
      z = do_4_ ## T ((int)z); \
      break; \
  }\
  for (j = 1; j < get_i (); j++) { \
    a[i+j] = accum * b[i+j*get_i()] / c[j]; \
    b[j] = b[j] - a[j-1]*x; \
    x += b[j-1] + b[j+1]; \
    y *= c[j*i] += a[0] + b[0] * c[(int)x]; \
  } \
  for (j = 0; j < 8192; j++) { \
    a[j] = a[j] + b[j] * c[j]; \
  } \
}

#define L1(T) BODY(T) BODY(T) BODY(T) BODY(T) BODY(T) BODY(T) BODY(T) BODY(T)
#define L2(T) L1(T) L1(T) L1(T) L1(T) L1(T) L1(T) L1(T) L1(T)
#define L3(T) L2(T) L2(T) L2(T) L2(T) L2(T) L2(T) L2(T) L2(T)

#define FUNC(T) \
extern T do_1_ ## T(T, T, T, int); \
extern T do_2_ ## T(T); \
extern T do_3_ ## T(T); \
extern T do_4_ ## T(T); \
T func_ ## T (T x, T y, T z, T *a, T *b, T *c) \
{ \
  T accum = 0; \
  int i, j; \
  L2(T) \
  /*L2(T)*/ \
  return accum; \
}

FUNC(schar)
FUNC(uchar)
FUNC(short)
FUNC(ushort)
FUNC(int)
FUNC(uint)
FUNC(long)
FUNC(ulong)
FUNC(llong)
FUNC(ullong)
FUNC(float)
FUNC(double)
FUNC(ldouble)