The patch adds the loop end location to the loop metadata. This additional information can be used to improve the locations when generating remarks for loops.
Details
Diff Detail
Event Timeline
The patch adds the loop end location to the loop metadata. This additional information can be used to improve the locations when generating remarks for loops.
How, exactly, do you plan on using this information to make the remarks better? I thought about doing this when I added the location information to the loop metadata in the first place, and figured that pointing to the start of the loop would unambiguously identify it. This could be useful for highlighting the entire loop body without having an AST available. I'd like to know what you're thinking.
I agree that the loop header should enough to identify the loop as a user given the source code. By having the end location is metadata however, we could present the information explicitly to the user.
One thing I was thinking about was using this information to display the whole loop when emitting vectorization remarks, instead of just the loop header. This should be fairly straight forward and I could probably come up with a patch in the next couple of days. We could also use the range information to visually mark loops in the HTML optimization reports. Another thing we could do with the information is folding/hiding "cold" loop bodies in optimization reports per default.
I think that source range information could be useful to improve diagnostics for other constructs besides loops, but adding it to loops first seems like a good way to see if people think it's useful at all.
This should probably be interesting to have in opt-viewer. We don't actually know the type of the code region we're dealing with right now (loop, block, instruction) so this will need more work. (There is layering problem right now using Loop directly. Loop is in Analysis while DiagnosticInfo is in IR.)
lib/Analysis/LoopInfo.cpp | ||
---|---|---|
319 | I'd rather just leave this unset if we don't have an ending location. This makes it easy to differentiate when we don't have an ending location from when we do (and adjust our messaging accordingly). | |
321 | I suggest that you add a 'break;' here, and then also add a comment above saying that the first debug location is taken to be the start of the loop, and the second taken to be the end of the loop. |
I've removed the End variable, added an early return after after we found the second DebugLoc and also added a comment.
As I do not have commit privileges it would be great if somebody could commit this patch (already marked as ready to land). Thank you very much.
Also there is an companion Clang patch D25764
I'd rather just leave this unset if we don't have an ending location. This makes it easy to differentiate when we don't have an ending location from when we do (and adjust our messaging accordingly).