------- Comment #1 from dberlin at gcc dot gnu dot org  2007-08-30 15:24 -------
Subject: Re:  New: Missed opportunities for vectorization due to PRE

On 30 Aug 2007 02:55:17 -0000, spop at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> The following loop showing up in the top time users in capacita.f90 is
> not vectorized because the loop latch block is non empty:
>
> ./capacita.f90:51: note: ===== analyze_loop_nest =====
> ./capacita.f90:51: note: === vect_analyze_loop_form ===
> ./capacita.f90:51: note: not vectorized: unexpected loop form.
> ./capacita.f90:51: note: bad loop form.
> ./capacita.f90:9: note: vectorized 0 loops in function.
>
> This block contains the following code that comes from the
> partial redundancy elimination pass:
>
>       bb_14 (preds = {bb_13 }, succs = {bb_13 })
>       {
>       <bb 14>:
>         # VUSE <SFT.109_593> { SFT.109 }
>         pretmp.166_821 = g.dim[1].stride;
>         goto <bb 13>;
>
>       }
>

PRE is just invariant hoisting.  If we didn't, something else would (LIM).


> Now, if I disable the PRE with -fno-tree-pre, I get another problem on
> the data dependence analysis:
>
>         base_address: &d1
>         offset from base address: 0
>         constant offset from base address: 0
>         step: 0
>         aligned to: 128
>         base_object: d1
>         symbol tag: d1
>         FAILED as dr address is invariant
>
> /home/seb/ex/capacita.f90:46: note: not vectorized: unhandled data-ref
> /home/seb/ex/capacita.f90:46: note: bad data references.
> /home/seb/ex/capacita.f90:4: note: vectorized 0 loops in function.
>
> This fail corresponds to the following code in tree-data-ref.c
>
>       /* FIXME -- data dependence analysis does not work correctly for objects
> with
>          invariant addresses.  Let us fail here until the problem is fixed.  
> */
>       if (dr_address_invariant_p (dr))
>         {
>           free_data_ref (dr);
>           if (dump_file && (dump_flags & TDF_DETAILS))
>             fprintf (dump_file, "\tFAILED as dr address is invariant\n");
>           ret = false;
>           break;
>         }
>
> Due to the following statement:
>
> # VUSE <d1_143> { d1 }
> d1.33_86 = d1;
>
> So here the data reference is for d1 that is a read with the following tree:
>
>     arg 1 <var_decl 0xb7be01cc d1 type <real_type 0xb7b4eaf8 real4>
>         addressable used public static SF file /home/seb/ex/capacita.f90 line
> 11 size <integer_cst 0xb7b4163c 32> unit size <integer_cst 0xb7b41428 4>
>         align 32
>         chain <var_decl 0xb7be0170 d2 type <real_type 0xb7b4eaf8 real4>
>             addressable used public static SF file /home/seb/ex/capacita.f90
> line 11 size <integer_cst 0xb7b4163c 32> unit size <integer_cst 0xb7b41428 4>
>             align 32 chain <var_decl 0xb7be0114 eps0>>>
>
> I don't really know how this could be handled as a data reference,
> because that statement has a VUSE but the type of d1 is scalar.

Yes, but it is a global, and should be looked at as any other load is.
:)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33244

Reply via email to