Michael Matz <m...@suse.de> writes: >> Ira Rosen <i...@il.ibm.com> writes: >> >> How about, as Micha suggested, print the location of the loop >> >> we currently investigate from vectorize_loops () where we >> >> call find_loop_location () instead? >> > >> > The problem is that a dump of a single loop can be pretty long, and "start >> > to analyze loop..."/"finish to analyze loop..." may be not visible enough. >> > I am OK with adding these printings though (in addition to line numbers). >> > >> > I understand why you didn't like to see the file location, but what's the >> > problem with the line number? >> >> +1 FWIW. I found these per-line locations really useful when doing >> the strided load/store stuff. > > Really? Because the dumper always prints the location of the loop (i.e. > its first line), not the location of the individual statements. Therefore > anything searching for file:line number will match all lines connected > with dealing with one loop, there's no differentiation between them. And > hence I also don't see Iras point. Searching for file:line from > file start before Richis changes would get you to the start where the loop > is dealt with, and then not a bit further because all lines would be so > prefixed. Searching from file end would get you to the end of the loop > processing (with the final decision), and also not further because of the > same prefix everywhere. > > So, no, I don't see how to prefix every line with the same prefix provides > anything useful. Can you show me how it was useful to you?
I suppose it's just personal preference. I look at the dumps using less, and search for the line number. That highlights all the lines in the loop I care about. It just seemed like a very nice visual cue when the relevant part of the dump was longer than a page. Richard
