This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/33244] Missed opportunities for vectorization due to PRE
- From: "dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Aug 2007 15:24:40 -0000
- Subject: [Bug tree-optimization/33244] Missed opportunities for vectorization due to PRE
- References: <bug-33244-7780@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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
<gcc-bugzilla@gcc.gnu.org> 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