This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] vectorizer phi-used-after-loop bug fix





> This is just a loop exit copy node that is part of loop closed ssa form.
> As it is a phi with one argument, it is safe to simply say that it is a
> copy.
>
> It is literally equivalent to the statement:
> sfirst_194 = sfirst_20
>
yes, I know, but since the loop is going to iterate only n/VF iterations
(instead of n iterations) neither sfirst_20 nor sfirst_194 will get the
value it is supposed to get at the end of the loop execution, unless we do
something special. We don't bother to do something special because we don't
think it is used after the loop (we just neglected to check that for
sfirst_20). It is easy to compute the value that sfirst_20 should take
after the loop, but we just don't do it yet (we will, soon).

dorit

Daniel Berlin <dberlin@dberlin.org> wrote on 31/01/2005 18:48:21:

>
>
> On Mon, 31 Jan 2005, Dorit Naishlos wrote:
>
> >
> >
> >
> >
> > In mark_stmts_to_be_vectorized we try to identify all stmts that need
to be
> > vectorized; in particular we want to identify which IVs can be ignored
> > (e.g, cause they are only used for array indexing) and which can't be
> > ignored (e.g, cause they are used outside the loop) and need special
> > handling (which we don't support yet, but we will soon). In the
meantine,
> > the problem is that we neglect to check whether phi nodes are used out
of
> > the loop (we only check the uses of regular stmts). Janis reported to
us a
> > case of miscompilation in SPEC that suffers from this problem. This is
the
> > situation that we weren't handling:
> >
> >    # ivtmp.1197_270 = PHI <256(34), ivtmp.1197_244(35)>;
> >    # ch_269 = PHI <256(34), ch_118(35)>;
> >>>  # sfirst_20 = PHI <sfirst_58(34), sfirst_113(35)>;
> > <LOOP>:;
> >    *sfirst_20 = -1;
> >    sfirst_113 = sfirst_20 + 4B;
> >    ch_118 = ch_269 - 1;
> >    ivtmp.1197_244 = ivtmp.1197_270 - 1;
> >    if (ivtmp.1197_244 != 0) goto <L45>; else goto <LOOP_EXIT>;
> > <L45>:;
> >    goto <bb 20> (<LOOP>);
> >
> >>>  # sfirst_194 = PHI <sfirst_20(20)>;
> > <LOOP_EXIT>:;
> >    sfirst_72 = sfirst_194 + -1020B;
> >    ...
> >
> > I can't reproduce this problem with the current mainline snapshot (I
could
> > with an older one), but I guess this situation may occur, so we need to
> > detect such phis and avoid vectorization for now.
>
> This is just a loop exit copy node that is part of loop closed ssa form.
> As it is a phi with one argument, it is safe to simply say that it is a
> copy.
>
> It is literally equivalent to the statement:
> sfirst_194 = sfirst_20
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]