This is an archive of the discontinued LLVM Phabricator instance.

Improved Diagnostics and Extended vectorize(enable)
ClosedPublic

Authored by tyler.nowicki on Aug 21 2015, 6:06 PM.

Details

Summary

This patch is the combination of several llvm patches that were submitted to the mailing list. There are a couple of clang patches also on the mailing list, but they are small and should easily be reviewed. If you would prefer to see the features split out, please review the patches on the mailing list.

From the list: I’ve been working on the vectorization diagnostics a little more. The first patch makes sure the analysis diagnostics are printed unless a disabling hint is provided. And the two pairs of LLVM and Clang patches make the diagnostic messages easier to understand and extend the vectorize(enable) hint to override the mem-pointer check threshold.

The new diagnostics are:

remark: loop not vectorized: cannot prove it is safe to reorder floating-point operations; allow reordering by specifying '#pragma clang loop vectorize(enable)' before the loop or by providing the compiler option '-ffast-math’.

and

remark: loop not vectorized: cannot prove it is safe to reorder memory operations; allow reordering by specifying '#pragma clang loop vectorize(enable)' before the loop. If the arrays will always be independent specify '#pragma clang loop vectorize(assume_safety)' before the loop or provide the 'restrict' qualifier with the independent array arguments. Erroneous results will occur if these options are incorrectly applied!

Using 'vectorize(enable)' to reorder memory operations is always safe (but not for fp ops), where as using 'vectorize(assume_safety)' might be dangerous. I removed the references to the mem-check threshold because I realized only compiler developers would know what it means.

Feedback is appreciated!

Diff Detail

Event Timeline

tyler.nowicki retitled this revision from to Improved Diagnostics and Extended vectorize(enable).
tyler.nowicki updated this object.
tyler.nowicki updated this object.
tyler.nowicki added reviewers: hfinkel, vsk.
tyler.nowicki added a subscriber: llvm-commits.
vsk edited edge metadata.Aug 21 2015, 11:42 PM

Just nitpicks from me (comments inline).

I'd run git blame on some of these files and get one or two more reviewers.

include/llvm/Analysis/LoopAccessAnalysis.h
79 ↗(On Diff #32891)

Nitpick, but from the coding style document: "Variable names should be nouns (as they represent state)". "VectorizationForced" might be a good compromise (and it's consistent).

lib/Analysis/LoopAccessAnalysis.cpp
30 ↗(On Diff #32891)

Same nitpick, see above.

lib/Transforms/Vectorize/LoopVectorize.cpp
933

It'd be helpful to restructure this code to return early when possible. E.g;

if (getWidth() == 1) return LV_NAME
if (getForce() == LVH::Disabled) return LV_NAME
if (getForce() != LVH::Enabled && getWidth() <= 1 && getInterleave() <= 1) return LV_NAME
return DI:AlwaysPrint

You may have to double-check that logic. Also, the third conditional looks like it could be simplified (given the first two).

934

Please add a newline (and perhaps a comment?) before allowReordering().

tyler.nowicki edited edge metadata.

Thanks for the review. I've updated the patch.

I noticed that no_fpmath wasn't able to correctly test the generation of analysis remarks without specifying -pass-remarks-analysis. I moved the test to no_switch. This test always fails and thus will emit an analysis remark when vectorization is forced.

vsk added a comment.Aug 25 2015, 9:10 AM

This looks fine to me. Could someone more familiar with LoopVectorize chime in?

Hi Tyler,

Please find some comments/questions from me inline:

lib/Analysis/LoopAccessAnalysis.cpp
32–33 ↗(On Diff #33038)

From the description it's not clear what the number stands for (I'd expect force-vectorization to be boolean). Could you please reword this somehow?

lib/Transforms/Vectorize/LoopVectorize.cpp
847

Why do we change this (default?) value?

932–933

Don't we start returning AlwaysPrint for all vectorized loops if no hint is specified (getForce() == LoopVectorizeHints::FK_Undefined, getWidth() == 4/8/16)?

1537

Why is allowReordering a part of ThresholdReached?

1822–1824

Why do we distinguish these two? If we don't want to see one of them in -R-reports, should we just make it DEBUG(dbgs() << "...") instead of emitOptimizationRemarkAnalysis?

Hi Michael,

Thanks for the comments. I made some changes, replies inline.

Tyler

lib/Transforms/Vectorize/LoopVectorize.cpp
932–933

No. Only when a hint is specified. This really means that the user only sees the analysis when vectorization fails on a loop with the hint enabled. If vectorization is possible, the user rarely sees any analysis. If there is something wrong with the loop then they will see the analysis.

1537

So vectorize(enable) can be used to override the threshold. But a comment in another discussion asked for another maximum threshold to prevent huge code. Thus we have two thresholds.

1822–1824

Vectorization analysis remarks are Always Printed when a vectorization loop hint is provided. We don't want to print interleaving analysis remarks when a vectorization loop hint is provided.

In the future we should, but that is for another patch. Part of the changes that should go in related to thise include detangling the metadata for enabling vectorization. Right now interleave(enable) and vectorize(enable) use the same metadata ...vectorize.enable.

mzolotukhin accepted this revision.Aug 26 2015, 3:13 PM
mzolotukhin added a reviewer: mzolotukhin.

Hi Tyler,

Thanks for the explanation - please find my replies inline. They are mostly cosmetic, so in general the patch looks good to me.

Michael

lib/Transforms/Vectorize/LoopVectorize.cpp
937–943

It's a bit unclear, what getWidth() has to do with reordering of operations. Do we basically check that the loop has any vectorization hint attached to it (and that it's not "don't vectorize this loop")? If my understanding is correct, could you please mention it in the comment somehow?

1537

I think I wasn't clear enough - I meant that while we do want to check this condition, it shouldn't be computed as a part of ThresholdReached variable, because semantically it doesn't belong there. I meant that we just need to pull out && !Hints.allowReordering to the check below.

This revision is now accepted and ready to land.Aug 26 2015, 3:13 PM
tyler.nowicki added inline comments.Aug 26 2015, 4:08 PM
lib/Transforms/Vectorize/LoopVectorize.cpp
937–943

I'll modify the comment to make it a little more clear that an enabling hint indicates reordering.

vsk closed this revision.Aug 1 2016, 6:28 PM

Done in llvm/r244523