public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* [autovect] Why all these redundant computations?
@ 2005-08-01 12:31 Sebastian Pop
  2005-08-01 14:26 ` Dorit Naishlos
  0 siblings, 1 reply; 4+ messages in thread
From: Sebastian Pop @ 2005-08-01 12:31 UTC (permalink / raw)
  To: gcc

Hello,

I was just looking at the output of the data dep analyzer for
ltrans-1.c and I was quite surprised to see that array indexes are
analyzed twice, as in the following output:

(analyze_array 
  (ref = u[D.1485_16];
)
(analyze_scalar_evolution 
  (loop_nb = 1)
  (scalar = D.1485_16)
(get_scalar_evolution 
  (scalar = D.1485_16)
  (scalar_evolution = {0, +, 1336}_1))
(set_scalar_evolution 
  (scalar = D.1485_16)
  (scalar_evolution = {0, +, 1336}_1))
)
(instantiate_parameters 
  (loop_nb = 1)
  (chrec = {0, +, 1336}_1)
  (res = {0, +, 1336}_1))
)

Here D.1485_16 has an evolution already stored in the cache.  However,
just below we get a full recomputation of the same D.1485_16:

(analyze_scalar_evolution 
  (loop_nb = 1)
  (scalar = D.1485_16)
(get_scalar_evolution 
  (scalar = D.1485_16)
  (scalar_evolution = {0, +, 1336}_1))
(analyze_scalar_evolution 
  (loop_nb = 1)
  (scalar = i_3)
(get_scalar_evolution 
  (scalar = i_3)
  (scalar_evolution = {0, +, 1}_1))
(analyze_initial_condition 
  (loop_phi_node = 
i_3 = PHI <i_20(8), 0(5)>;)
  (init_cond = 0))
(analyze_evolution_in_loop 
  (loop_phi_node = i_3 = PHI <i_20(8), 0(5)>;)
(add_to_evolution 
  (loop_nb = 1)
  (chrec_before = 0)
  (to_add = 1)
  (res = {0, +, 1}_1))
  (evolution_function = {0, +, 1}_1))
(set_scalar_evolution 
  (scalar = i_3)
  (scalar_evolution = {0, +, 1}_1))
)
(analyze_scalar_evolution 
  (loop_nb = 1)
  (scalar = 1336)
(get_scalar_evolution 
  (scalar = 1336)
  (scalar_evolution = 1336))
)
(set_scalar_evolution 
  (scalar = D.1485_16)
  (scalar_evolution = {0, +, 1336}_1))
)

The problem seems to be that analyze_offset_expr calls the scev
analyzer explicitely asking for recomputation (third parameter is
true):

  /* 2. Variable. Try to substitute with initial_condition of the corresponding
     access_fn in the current loop.  */
  if (SSA_VAR_P (expr))
    {
      tree access_fn = analyze_scalar_evolution (loop, expr, true, 
						 &unknown_evolution);

Why should we start the analysis from scratch in this case?  The same
question could be asked for all the uses of analyze_scalar_evolution
in the vectorizer...  Grepping for analyze_scalar_evolution, you get
the following places (in autovect branch) that explicitely ask for
scev recomputation:

tree-vect-analyze.c:551:      access_fn = analyze_scalar_evolution (loop, def, true, &unknown_evolution);
tree-vect-analyze.c:2226:	(loop, analyze_scalar_evolution (loop, PHI_RESULT (phi), true, 
tree-vect-transform.c:605:        access_fn = analyze_scalar_evolution (loop, def, true,
tree-vect-transform.c:2548:      access_fn = analyze_scalar_evolution (loop, PHI_RESULT (phi), true,
tree-data-ref.c:940:  tree access_fn = analyze_scalar_evolution (loop, ptr_ref, true, 
tree-data-ref.c:1151:      tree access_fn = analyze_scalar_evolution (loop, expr, true, 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [autovect] Why all these redundant computations?
  2005-08-01 12:31 [autovect] Why all these redundant computations? Sebastian Pop
@ 2005-08-01 14:26 ` Dorit Naishlos
  2005-08-01 14:43   ` Daniel Berlin
  0 siblings, 1 reply; 4+ messages in thread
From: Dorit Naishlos @ 2005-08-01 14:26 UTC (permalink / raw)
  To: Sebastian Pop; +Cc: gcc, Ira Rosen





> ...
>
> The problem seems to be that analyze_offset_expr calls the scev
> analyzer explicitely asking for recomputation (third parameter is
> true):
>
> ...
>
> Why should we start the analysis from scratch in this case?  The same
> question could be asked for all the uses of analyze_scalar_evolution
> in the vectorizer...  Grepping for analyze_scalar_evolution, you get
> the following places (in autovect branch) that explicitely ask for
> scev recomputation:
>

I don't think there was an intention to force recomputation - probably just
overlooked what the third argument actually stands for. These occurrences
could probably be changed to false.

dorit

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [autovect] Why all these redundant computations?
  2005-08-01 14:26 ` Dorit Naishlos
@ 2005-08-01 14:43   ` Daniel Berlin
  2005-08-01 15:00     ` Sebastian Pop
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Berlin @ 2005-08-01 14:43 UTC (permalink / raw)
  To: Dorit Naishlos; +Cc: Sebastian Pop, gcc, Ira Rosen

On Mon, 2005-08-01 at 17:27 +0300, Dorit Naishlos wrote:
> 
> 
> 
> > ...
> >
> > The problem seems to be that analyze_offset_expr calls the scev
> > analyzer explicitely asking for recomputation (third parameter is
> > true):
> >
> > ...
> >
> > Why should we start the analysis from scratch in this case?  The same
> > question could be asked for all the uses of analyze_scalar_evolution
> > in the vectorizer...  Grepping for analyze_scalar_evolution, you get
> > the following places (in autovect branch) that explicitely ask for
> > scev recomputation:
> >
> 
> I don't think there was an intention to force recomputation - probably just
> overlooked what the third argument actually stands for. These occurrences
> could probably be changed to false.
> 

Yeah, i agree with dorit.
The only other possible reason i can think of is that it fixed a bug
somewhere due to not properly invalidating the cache, and that fix was
just copied around.

> dorit
> 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [autovect] Why all these redundant computations?
  2005-08-01 14:43   ` Daniel Berlin
@ 2005-08-01 15:00     ` Sebastian Pop
  0 siblings, 0 replies; 4+ messages in thread
From: Sebastian Pop @ 2005-08-01 15:00 UTC (permalink / raw)
  To: Daniel Berlin; +Cc: Dorit Naishlos, gcc, Ira Rosen

Daniel Berlin wrote:
> On Mon, 2005-08-01 at 17:27 +0300, Dorit Naishlos wrote:
> > 
> > I don't think there was an intention to force recomputation - probably just
> > overlooked what the third argument actually stands for. These occurrences
> > could probably be changed to false.
> > 
> 
> Yeah, i agree with dorit.
> The only other possible reason i can think of is that it fixed a bug
> somewhere due to not properly invalidating the cache, and that fix was
> just copied around.
> 

Okay, then I'll try to bootstrap and test with these flags passed to
false.

Thanks.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-08-01 15:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-08-01 12:31 [autovect] Why all these redundant computations? Sebastian Pop
2005-08-01 14:26 ` Dorit Naishlos
2005-08-01 14:43   ` Daniel Berlin
2005-08-01 15:00     ` Sebastian Pop

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).