Re: [patch] vectorizer: maintain location information, and ping

[Dorit Naishlos <DORIT at il dot ibm dot com>]

Richard Henderson <rth@redhat.com> wrote on 02/02/2005 00:19:00:

> On Mon, Jan 31, 2005 at 06:12:30PM +0200, Dorit Naishlos wrote:
> > 1. setup code in the loop preheader for: (1) initialization of a vector
> > with a constant/invariant value, (2) mask calculation and extra load
for
> > software-pipelined unaligned-load handling, (3) address calculation
code,
> > including new IVs. These can get the location of the original scalar
stmt
> > that prompted the creation of this code.
>
> Yeah, I dunno what the best thing here is.  Perhaps the lineno of the
> start of the loop?  Certainly I would find it confusing to be stepping
> through the pre-header and have the debugger bounce randomly through
> statements within the loop.  It might work out just as well to not give
> any line number info for them.  You'd have to see what actually happens
> when you debug such loops.
>

playing a bit with gdb looks like the preheader code is already associated
with the beginning of the loop, so maybe there's nothing to do here.


> > 2. new code created by loop peeling (to align loop-bound or
> > memory-accesses) including new control code, new loops body, and setup
code
> > before each loop to calculate number of iterations and such. The stmts
in
> > the new peel-loops can get the location info of the original stmts they
are
> > a duplicate of. The rest, maybe best left without location info.
>
> A peel, however, is easy and the obvious thing should be done.
>

here also, stepping with gdb looks as if nothing special needs to be done
for the peel loops - i.e, it shows the correct line numbers for the peel
loops already. The only remaining confusing bit as far as I could see is at
the point between the main loop and the (epilog) peel loop - the code there
gets a line number after the loop. Giving it the line number of the
beginning of the loop would be less confusing I think. Anyhow, it looks
like the major thing that had to be done was to copy the location
information to the new vector-stmt. Further improvements seem less critical
(and would also involve much more changes to the code) so I think we can
wait with that for 4.1.

thanks,
dorit


> > Shall we prepare a patch for these cases too (for 4.0)?
>
> Please.
>
> >       * tree-vectorizer.c (slpeel_make_loop_iterate_ntimes): Copy
> >       EXPR_LOCUS from orig_cond to the new cond_stmt.
> >       (vect_finish_stmt_generation): Copy EXPR_LOCUS from stmt to
> >       the new vec_stmt.
>
> Ok.
>
>
> r~