struct-reorg optimization

Daniel Berlin dberlin@dberlin.org
Thu Jul 19 22:57:00 GMT 2007


On 7/10/07, Olga Golovanevsky <OLGA@il.ibm.com> wrote:
>
> This patch implements structure peeling, that is one of struct-reorg
> optimizations developed on struct-reorg-branch. A structure type can be
> peeled into separate fields, or groups of them, according to profile
> information, or  deliberately. The gain is to utilize spatial locality,
> when, for example, one of the fields is sequentially accessed through
> array elements. Then separating this field from others allows to make
> separation in array allocation, and thus release cache from irrelevant
> data fetched with other fields.
>
> The full description of this optimization is at the beginning of
> struct-reorg.c (attached below).
>
> The optimization is global, both types of accesses - through pointers
> and  array refs - are handled. When allocation is made through malloc,
> it is replaced by allocations of peeled structures. Only build-in malloc
> is supported right now, but it can be easily extended.
>
> In this patch, the decision how to peel is made by frequency based model,
> where frequency of field accesses can be calculated through profiling or
> statically predicted as with -fbranch-probabilitied flag. When there is
> no such info, structure gets completely peeled. (The struct-reorg-branch
> contains much more accurate model which is based on the calculation of
> distance between accesses, but it's also heavier.)
> The -fipa-struct-reorg flag activates this optimization.
>
> The patch makes strong use of ipa-type-escape analysis, that provide
> safety of this optimization. Also changes required for ipa-type-escape
> to support POITER_PLUS_EXPR are part of this patch.
>



> With this patch:
>       - two structures f1_neuron and  xyz got peeled in 179. art ,
>       +44% w/o profiling and +33% with profiling
>
>       - the structures  NEXT_MOVE got peeled, the structure CHESS_POSITION
>       can be peeled, but interfere with another optimization that
>       generated BIT_FIELD_REFs in 186.crafty; many other structures escape,
>       no influence on performance
>
>       - the structure MMNODE got peeled; many others escape,
>       no influence on performance
>
> Bootstraped and tested (except  fortran) on ppc .

Comments on struct-reorg.c:


1. The comments in strip_t ype do not make clear what it does
Just based on looking at it, it should be using POINTER_TYPE_P, not
TREE_CODE (type) == POINTER_TYPE
2. why is get_type_name returning a char * and not a const char *?
3. why is get_type_var using DECL_ARG_TYPE?
4.
  if (SSA_NAME_IS_DEFAULT_DEF(before_cast))
    return false;
Should be
  if (SSA_NAME_IS_DEFAULT_DEF (before_cast))
    return false;
5. your offset/base splitting code seems to be trying to approximate
exactly what get_ref_and_base_extent will do for you.

6. In build_basic_struct, why are you touching C_* fields?

7. Don't use CONSTANT_CLASS_P and simple_cst_equal, just call
operand_equal_p on rhs

8. It seems you assume struct sizes fit in unsigned int in a lot of
places, when they should actually be HOST_WIDE_INT

I see no problems with the changes you make in the patch (ie the patch
to ipa-type-escape.c)



More information about the Gcc-patches mailing list