Re: [PING] [PATCH] Optional alternative base_expr in finding basis for CAND_REFs

[Jeff Law]

On 12/03/13 08:52, Yufeng Zhang wrote:

I still don't like it.  It's using the wrong and too expensive tools
to do
stuff.  What kind of bases are we ultimately interested in?  Browsing
the code it looks like we're having

   /* Base expression for the chain of candidates:  often, but not
      always, an SSA name.  */
   tree base_expr;

which isn't really too informative but I suppose they are all
kind-of-gimple_val()s?  That said, I wonder if you can simply
use get_addr_base_and_unit_offset in place of get_alternative_base (),
ignoring the returned offset.

'base_expr' is essentially the base address of a handled_component_p,
e.g. ARRAY_REF, COMPONENT_REF, etc.  In most case, it is the address of
the object returned by get_inner_reference ().

Given a test case like the following:

typedef int arr_2[20][20];

void foo (arr_2 a2, int i, int j)
{
   a2[i+10][j] = 1;
   a2[i+10][j+1] = 1;
   a2[i+20][j] = 1;
}

The IR before SLSR is (on x86_64):

   _2 = (long unsigned int) i_1(D);
   _3 = _2 * 80;
   _4 = _3 + 800;
   _6 = a2_5(D) + _4;
   *_6[j_8(D)] = 1;
   _10 = j_8(D) + 1;
   *_6[_10] = 1;
   _12 = _3 + 1600;
   _13 = a2_5(D) + _12;
   *_13[j_8(D)] = 1;

The base_expr for the 1st and 2nd memory reference are the same, i.e.
_6, while the base_expr for a2[i+20][j] is _13.

_13 is essentially (_6 + 800), so all of the three memory references
essentially share the same base address.  As their strides are also the
same (MULT_EXPR (j, 4)), the three references can all be lowered to
MEM_REFs.  What this patch does is to use the tree affine tools to help
recognize the underlying base address expression; as it requires looking
into the definitions of SSA_NAMEs, get_addr_base_and_unit_offset ()
won't help here.

Bill has helped me exploit other ways of achieving this in SLSR, but so
far we think this is the best way to proceed.  The use of tree affine
routines has been restricted to CAND_REFs only and there is the
aforementioned cache facility to help reduce the overhead.
Right and I think Bill's opinions should carry the weight here since he 
wrote the SLSR code and will likely be its maintainer.

So let's keep the cache per your data.  OK for the trunk.  Thanks for 
your patience and understanding.

jeff