This is the mail archive of the 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: maintain location information, and ping

Richard Henderson <> 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
> > software-pipelined unaligned-load handling, (3) address calculation
> > including new IVs. These can get the location of the original scalar
> > 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
> > before each loop to calculate number of iterations and such. The stmts
> > the new peel-loops can get the location info of the original stmts they
> > 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.


> > 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~

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