This is the mail archive of the
mailing list for the GCC project.
Re: [patch] vectorizer: maintain location information, and ping
- From: Dorit Naishlos <DORIT at il dot ibm dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Leehod Baruch <LEEHOD at il dot ibm dot com>
- Date: Sun, 6 Feb 2005 18:55:29 +0200
- Subject: Re: [patch] vectorizer: maintain location information, and ping
Richard Henderson <email@example.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
> > 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)?
> > * 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.