[Bug tree-optimization/33244] Missed opportunities for vectorization due to PRE

[matz at gcc dot gnu dot org]

--- Comment #3 from matz at gcc dot gnu dot org  2010-09-08 12:35 ---
Subject: Bug 33244

Author: matz
Date: Wed Sep  8 12:34:52 2010
New Revision: 163998

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163998
Log:
PR tree-optimization/33244
* tree-ssa-sink.c (statement_sink_location): Don't sink into
empty loop latches.

testsuite/
PR tree-optimization/33244
* gfortran.dg/vect/fast-math-vect-8.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/vect/fast-math-vect-8.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sink.c


-- 


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

[Bug tree-optimization/33244] Missed opportunities for vectorization due to PRE

[matz at gcc dot gnu dot org]

--- Comment #2 from matz at gcc dot gnu dot org  2010-09-07 14:41 ---
Since the fix for PR44710 we can if-convert the conditions in the inner loop.
With http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00542.html we also
make sure that the latch block isn't filled, which in turn then triggers
the if-conversion.  This then reveals the rest of the problems, which are:

  * inlining needs to happen (our default parameters don't inline ginteg)
The patch above ensures this by making the functions internal
  * a library with vectorized logf needs to be available (libacml_mv for
instance)
The patch above works around this by getting rid of calls to log/sqrt
  * loop interchange needs to happen, because in the original testcase
we have:
  do i=0,Ng1
do j=0,Ng2
  G(i,j) = ...
exactly the wrong way around.  Our loop-interchange code is only
capable of vectorizing perfect nests, which here doesn't exist
as LIM and PRE move out some loop invariant expressions from the
inner to the outer loop.  If we weren't doing that, that itself would
already prevent vectorization.
The patch above works around this by doing the interchange by hand.


-- 


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

[Bug tree-optimization/33244] Missed opportunities for vectorization due to PRE

[dberlin at dberlin 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 -, 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 })
>   {
>   :
> # VUSE  { SFT.109 }
> pretmp.166_821 = g.dim[1].stride;
> goto ;
>
>   }
>

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 }
> d1.33_86 = d1;
>
> So here the data reference is for d1 that is a read with the following tree:
>
> arg 1 
> addressable used public static SF file /home/seb/ex/capacita.f90 line
> 11 size  unit size 
> align 32
> chain 
> addressable used public static SF file /home/seb/ex/capacita.f90
> line 11 size  unit size 
> align 32 chain >>
>
> 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