ix86_address_cost

ix86_address_cost

[Zdenek Dvorak]

Hello,

what is the purpose of the following code in ix86_address_cost:

  /* More complex memory references are better.  */
  if (parts.disp && parts.disp != const0_rtx)
     cost--;
?

It in effect claims that [reg] is more expensive than [reg - 4].
This leads ivopts to generate pretty weird code; for example on code
of type

for (i = 0; i < n; i++)
  {
    a[i] = something;
    b[i] = something;
    c[i] = something;
  }

it decides that it may be better to use an induction variable with
initial value 1:

for (ivtmp = 1; ivtmp - 1 < n; ivtmp++)
  {
    a[ivtmp - 1] = something;
    b[ivtmp - 1] = something;
    c[ivtmp - 1] = something;
  }

Since obviously we gain 1 in cost for every use in address, and lose
relatively little on having to express ivtmp - 1.

Zdenek

Re: ix86_address_cost

[Jan Hubicka]

> Hello,
> 
> what is the purpose of the following code in ix86_address_cost:
> 
>   /* More complex memory references are better.  */
>   if (parts.disp && parts.disp != const0_rtx)
>      cost--;
> ?
> 
> It in effect claims that [reg] is more expensive than [reg - 4].
> This leads ivopts to generate pretty weird code; for example on code
> of type

The main idea behind this hack is to force CSE to use complex addressing
modes (ie if it uses reg-4 instead of reg2, one might hope for that
"reg2=reg-4" statement will get dead and elliminated completely).

This would ineed be interesting thing to re-benchmark so we see if it
still does any good.

Honza
> 
> for (i = 0; i < n; i++)
>   {
>     a[i] = something;
>     b[i] = something;
>     c[i] = something;
>   }
> 
> it decides that it may be better to use an induction variable with
> initial value 1:
> 
> for (ivtmp = 1; ivtmp - 1 < n; ivtmp++)
>   {
>     a[ivtmp - 1] = something;
>     b[ivtmp - 1] = something;
>     c[ivtmp - 1] = something;
>   }
> 
> Since obviously we gain 1 in cost for every use in address, and lose
> relatively little on having to express ivtmp - 1.
> 
> Zdenek

Re: ix86_address_cost

[Zdenek Dvorak]

Hello,

> > what is the purpose of the following code in ix86_address_cost:
> > 
> >   /* More complex memory references are better.  */
> >   if (parts.disp && parts.disp != const0_rtx)
> >      cost--;
> > ?
> > 
> > It in effect claims that [reg] is more expensive than [reg - 4].
> > This leads ivopts to generate pretty weird code; for example on code
> > of type
> 
> The main idea behind this hack is to force CSE to use complex addressing
> modes (ie if it uses reg-4 instead of reg2, one might hope for that
> "reg2=reg-4" statement will get dead and elliminated completely).
> 
> This would ineed be interesting thing to re-benchmark so we see if it
> still does any good.

this seems like a quite terrible way how to persuade CSE to do this.  Would
not it be better to add this "complicated address" bonus directly in
CSE, and let address_cost do just what it is supposed to -- compute cost of
the address?

Zdenek

Re: ix86_address_cost

[Jan Hubicka]

> Hello,
> 
> > > what is the purpose of the following code in ix86_address_cost:
> > > 
> > >   /* More complex memory references are better.  */
> > >   if (parts.disp && parts.disp != const0_rtx)
> > >      cost--;
> > > ?
> > > 
> > > It in effect claims that [reg] is more expensive than [reg - 4].
> > > This leads ivopts to generate pretty weird code; for example on code
> > > of type
> > 
> > The main idea behind this hack is to force CSE to use complex addressing
> > modes (ie if it uses reg-4 instead of reg2, one might hope for that
> > "reg2=reg-4" statement will get dead and elliminated completely).
> > 
> > This would ineed be interesting thing to re-benchmark so we see if it
> > still does any good.
> 
> this seems like a quite terrible way how to persuade CSE to do this.  Would
> not it be better to add this "complicated address" bonus directly in
> CSE, and let address_cost do just what it is supposed to -- compute cost of
> the address?

I would fully agree here if it matters :))

Honza
> 
> Zdenek