[LV] Share the LV illegality reporting with LoopVectorize. NFC.

[psamolysov]

Summary

The logic of the `LoopVectorizationLegality::reportVectorizationFailure`
method is extracted into a utility function which is exported through
the `LoopVectorize.h` header file and is available for
the LoopVectorize pass. The methods `createMissedAnalysis` as well as
`reportVectorizationFailure` were removed, they aren't required anymore.
The function `debugVectorizationFailure` is marked as static and is
available in LoopVectorize.cpp only.

[psamolysov]

Diff updated: rebased to the current master.

[psamolysov]

I'm sorry, does this patch look interesting for review?

[rengolin]

Sorry Pavel, tough week. it's at the top of my list.

[hsaito]

Sorry, I missed the original review request in the e-mail pile up. Yes, this is the direction I was suggesting. Thank you.

My preference is to have the utility declared in LoopVectorize.h as a more neutral place. If we had vectorizer utility .h/.cpp, that would have been ideal, What bothers me is Hints.vectorizeAnalysisPassName(). Anybody know why we use AlwaysPrint()?

Not a big fan of creating a new entry just for two parameters --- especially when those two parameters are probably the same for all cases. If we can always use LV_NAME, one of the two parameters can be eliminated.
If theLoop is the only thing left, passing it from all calls seems better than having two functions with the same name with same functionality (on in class and one at top level).

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp

7339

Do we need :: here?

7353

Same as above

[rengolin]

I agree with Hideki, this could be in LoopVectorize.h.

Also the function overload is confusing, better to just use the same function for all cases.

Once the pattern is done, refactoring is not that hard. If we have overloaded functions, refactoring is a lot harder.

cheers,
--renato

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp

7339

Doesn't make sense to me, given that it should be identical as calling the local function.

Also, this pattern is confusing, better to just use the same helper function on all cases.

[psamolysov]

@hsaito @rengolin I get your points, I'm going to remove private methods and do something with pass name in a couple of days.

[psamolysov]

The diff has been updated: private methods were removed, the function 'reportVectorizationFailure' was moved to LoopVectorize.cpp and declared in LoopVectorize.h (namespace llvm). I've removed the passName parameter and pass LV_NAME as pass name to ORE but this change breaks 3 regression tests:

• Transforms/LoopVectorize/control-flow.ll
• Transforms/LoopVectorize/no_switch.ll
• Transforms/LoopVectorize/pr38800.ll

They all run opt with -pass-remarks-missed='loop-vectorize'

@rengolin @hsaito I need you suggestions how to deal with the Hints.vectorizeAnalysisPassName() method, it is very long to always call it whenever the reportVectorizationFailure is invoked.

[psamolysov]

Rebase on the current master

[rengolin]

In D62997#1551946, @psamolysov wrote:

The diff has been updated: private methods were removed, the function 'reportVectorizationFailure' was moved to LoopVectorize.cpp and declared in LoopVectorize.h (namespace llvm). I've removed the passName parameter and pass LV_NAME as pass name to ORE but this change breaks 3 regression tests:

I'm assuming that the pass name isn't just LV_NAME, but whichever pass is using that function, which now that it's higher level, can be anything.

@rengolin @hsaito I need you suggestions how to deal with the Hints.vectorizeAnalysisPassName() method, it is very long to always call it whenever the reportVectorizationFailure is invoked.

I don't have a better idea on the top of my head, but this sounds like a change that can be done later as a quick refactory once someone comes up with a clever replacement.

I'd be ok having that for now... @hsaito may have a better idea, though.

--renato

[hsaito]

In D62997#1553998, @rengolin wrote:

In D62997#1551946, @psamolysov wrote:

The diff has been updated: private methods were removed, the function 'reportVectorizationFailure' was moved to LoopVectorize.cpp and declared in LoopVectorize.h (namespace llvm). I've removed the passName parameter and pass LV_NAME as pass name to ORE but this change breaks 3 regression tests:

I'm assuming that the pass name isn't just LV_NAME, but whichever pass is using that function, which now that it's higher level, can be anything.

@rengolin @hsaito I need you suggestions how to deal with the Hints.vectorizeAnalysisPassName() method, it is very long to always call it whenever the reportVectorizationFailure is invoked.

I don't have a better idea on the top of my head, but this sounds like a change that can be done later as a quick refactory once someone comes up with a clever replacement.

I'd be ok having that for now... @hsaito may have a better idea, though.

--renato

I don't have a better idea, but I think the 3 failed tests are worth looking into, in trying to understand why we would want to emit the remark always. Which test failed?

[psamolysov]

@hsaito

Here is the log of lit on Vectorization:

• Testing: 319 tests, 8 threads --

Testing: 0 .. 10.. 20.. 30.. 40.
FAIL: LLVM :: Transforms/LoopVectorize/control-flow.ll (150 of 319)

• TEST 'LLVM :: Transforms/LoopVectorize/control-flow.ll' FAILED ****

Script:

: 'RUN: at line 1'; bin\opt.exe < llvm\test\Transforms\LoopVectorize\control-flow.ll -loop-vectorize -force-vector-width=4 -S -pass-remarks-missed='loop-vectorize' 2>&1 | bin\filecheck.exe llvm\test\Transforms\LoopVectorize\control-flow.ll

Exit Code: 1

Command Output (stdout):

$ ":" "RUN: at line 1"
$ "bin\opt.exe" "-loop-vectorize" "-force-vector-width=4" "-S" "-pass-remarks-missed=loop-vectorize"
$ "bin\filecheck.exe" "llvm\test\Transforms\LoopVectorize\control-flow.ll"

command stderr:

llvm\test\Transforms\LoopVectorize\control-flow.ll:13:10: error: CHECK: expected string not found in input

; CHECK: remark: source.cpp:5:9: loop not vectorized: loop control flow is not understood by vectorizer

^

<stdin>:1:1: note: scanning from here

remark: source.cpp:5:9: loop not vectorized: loop control flow is not understood by analyzer

^

error: command failed with exit status: 1

---

Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70
FAIL: LLVM :: Transforms/LoopVectorize/no_switch.ll (242 of 319)

• TEST 'LLVM :: Transforms/LoopVectorize/no_switch.ll' FAILED ****

Script:

: 'RUN: at line 1'; bin\opt.exe < llvm\test\Transforms\LoopVectorize\no_switch.ll -loop-vectorize -force-vector-width=4 -transform-warning -S 2>&1 | bin\filecheck.exe llvm\test\Transforms\LoopVectorize\no_switch.ll
: 'RUN: at line 2'; bin\opt.exe < llvm\test\Transforms\LoopVectorize\no_switch.ll -loop-vectorize -force-vector-width=1 -transform-warning -S 2>&1 | bin\filecheck.exe llvm\test\Transforms\LoopVectorize\no_switch.ll -check-prefix=NOANALYSIS

: 'RUN: at line 3'; bin\opt.exe < llvm\test\Transforms\LoopVectorize\no_switch.ll -loop-vectorize -force-vector-width=4 -transform-warning -pass-remarks-missed='loop-vectorize' -S 2>&1 | bin\filecheck.exe llvm\test\Transforms\LoopVectorize\no_switch.ll -check-prefix=MOREINFO

Exit Code: 1

Command Output (stdout):

$ ":" "RUN: at line 1"
$ "bin\opt.exe" "-loop-vectorize" "-force-vector-width=4" "-transform-warning" "-S"
$ "bin\filecheck.exe" "llvm\test\Transforms\LoopVectorize\no_switch.ll"

command stderr:

llvm\test\Transforms\LoopVectorize\no_switch.ll:5:10: error: CHECK: expected string not found in input

; CHECK: remark: source.cpp:4:5: loop not vectorized: loop contains a switch statement

^

<stdin>:1:1: note: scanning from here

warning: source.cpp:4:5: loop not vectorized: the optimizer was unable to perform the requested transformation; the transformation might be disabled or specified as part of an unsupported transformation ordering

^

<stdin>:1:2: note: possible intended match here

warning: source.cpp:4:5: loop not vectorized: the optimizer was unable to perform the requested transformation; the transformation might be disabled or specified as part of an unsupported transformation ordering

^

error: command failed with exit status: 1

---

Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80
FAIL: LLVM :: Transforms/LoopVectorize/pr38800.ll (272 of 319)

• TEST 'LLVM :: Transforms/LoopVectorize/pr38800.ll' FAILED ****

Script:

: 'RUN: at line 1'; bin\opt.exe -loop-vectorize -force-vector-width=2 -pass-remarks-missed='loop-vectorize' -S < llvm\test\Transforms\LoopVectorize\pr38800.ll 2>&1 | bin\filecheck.exe llvm\test\Transforms\LoopVectorize\pr38800.ll

Exit Code: 1

Command Output (stdout):

$ ":" "RUN: at line 1"
$ "bin\opt.exe" "-loop-vectorize" "-force-vector-width=2" "-pass-remarks-missed=loop-vectorize" "-S"
$ "bin\filecheck.exe" "llvm\test\Transforms\LoopVectorize\pr38800.ll"

command stderr:

llvm\test\Transforms\LoopVectorize\pr38800.ll:3:10: error: CHECK: expected string not found in input

; CHECK: remark: <unknown>:0:0: loop not vectorized: integer loop induction variable could not be identified

^

<stdin>:1:1: note: scanning from here

remark: <unknown>:0:0: loop not vectorized

^

error: command failed with exit status: 1

---

Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 5.85s

---

Failing Tests (3):

  LLVM :: Transforms/LoopVectorize/control-flow.ll
  LLVM :: Transforms/LoopVectorize/no_switch.ll
  LLVM :: Transforms/LoopVectorize/pr38800.ll

Expected Passes    : 261
Unsupported Tests  : 55
Unexpected Failures: 3

[hsaito]

Looking at the expected output and the explanations on -Rpass* flags, it could be that those tests should be using -pass-remarks-analysis=loop-vectorize, instead of -pass-remarks-missed=loop-vectorize. Would you try?

In D62997#1557206, @psamolysov wrote:

@hsaito

Here is the log of lit on Vectorization:

• Testing: 319 tests, 8 threads --

Testing: 0 .. 10.. 20.. 30.. 40.
FAIL: LLVM :: Transforms/LoopVectorize/control-flow.ll (150 of 319)

• TEST 'LLVM :: Transforms/LoopVectorize/control-flow.ll' FAILED ****

Script:

: 'RUN: at line 1'; bin\opt.exe < llvm\test\Transforms\LoopVectorize\control-flow.ll -loop-vectorize -force-vector-width=4 -S -pass-remarks-missed='loop-vectorize' 2>&1 | bin\filecheck.exe llvm\test\Transforms\LoopVectorize\control-flow.ll

---

Snippet from https://llvm.org/docs/Vectorizers.html:

Many loops cannot be vectorized including loops with complicated control flow, unvectorizable types, and unvectorizable calls. The loop vectorizer generates optimization remarks which can be queried using command line options to identify and diagnose loops that are skipped by the loop-vectorizer.

Optimization remarks are enabled using:

-Rpass=loop-vectorize identifies loops that were successfully vectorized.

-Rpass-missed=loop-vectorize identifies loops that failed vectorization and indicates if vectorization was specified.

-Rpass-analysis=loop-vectorize identifies the statements that caused vectorization to fail. If in addition -fsave-optimization-record is provided, multiple causes of vectorization failure may be listed (this behavior might change in the future).

[psamolysov]

@hsaito Thanks, it solves almost all problems with the tests, but one test - no_switch.ll - requires a bit more work.

[psamolysov]

In tests -pass-remarks-missed changed to -pass-remarks-analysis.

[psamolysov]

The test no_switch.ll has been updated: the LV doesn't report remarks without -pass-remarks-missed='loop-vectorize' -pass-remarks-analysis='loop-vectorize', so the test from the CHECK section is removed. I have no idea why, but remarks with lambdas through the code emitted via OptimizationRemarkMissed, not OptimizationRemarkAnalysis (if I right understand, 'Missed' means the pass has not been applied by any reasons during optimization).

[hsaito]

In D62997#1589461, @psamolysov wrote:

The test no_switch.ll has been updated: the LV doesn't report remarks without -pass-remarks-missed='loop-vectorize' -pass-remarks-analysis='loop-vectorize', so the test from the CHECK section is removed. I have no idea why, but remarks with lambdas through the code emitted via OptimizationRemarkMissed, not OptimizationRemarkAnalysis (if I right understand, 'Missed' means the pass has not been applied by any reasons during optimization).

Thanks, @psamolysov. No more LIT test failures? I don't understand the issue with no_switch.ll either, but trying to understand that shouldn't block this patch.

[psamolysov]

I've renamed the createLVMissedAnalysis method to createLVAnalysis: 'Missed' confuses me because means that a Missed report will be emitted while in fact a Analysis one will be.

[psamolysov]

@hsaito The test no_switch.ll failed because remarks aren't written now by default, so without -pass-remarks-analysis. I've just removed the corresponding check from the test. But, I think, the NFC label from diff/commit should also be removed in this case because the behavior is changed a little bit. No other problems with tests in the LoopVectorize directory. If this diff is applied, the entire set of tests passes.

[rengolin]

In D62997#1591113, @psamolysov wrote:

@hsaito The test no_switch.ll failed because remarks aren't written now by default, so without -pass-remarks-analysis. I've just removed the corresponding check from the test. But, I think, the NFC label from diff/commit should also be removed in this case because the behavior is changed a little bit. No other problems with tests in the LoopVectorize directory. If this diff is applied, the entire set of tests passes.

This is also not NFC because it changes the option name. In that case, we need to take a longer look and make sure it won't break anyone else and maybe even consider warning the community (which heavily uses opt around).

So, I'd recommend we don't change the name of the pass on this patch, keep the remark and maintain the NFC tag.

If we want to change the name, or behaviour, we can do so later.

[psamolysov]

@rengolin I think the pass name is not the problem. Before the method was used and the method just asks "Always Print":

const char *LoopVectorizeHints::vectorizeAnalysisPassName() const {
  if (getWidth() == 1)
    return LV_NAME;
  if (getForce() == LoopVectorizeHints::FK_Disabled)
    return LV_NAME;
  if (getForce() == LoopVectorizeHints::FK_Undefined && getWidth() == 0)
    return LV_NAME;
  return OptimizationRemarkAnalysis::AlwaysPrint;
}

For example,

; CHECK: remark: source.cpp:5:9: loop not vectorized: loop control flow is not understood by vectorizer

works on the master branch even without -pass-remarks-missed/-pass-remarks-analysis options. Writing into the OptimizationRemarkMissed (for example, loop not vectorized (Force=true, Vector Width=4) requires -pass-remarks-missed even on the master branch. New behavior: reasons reported only when the -pass-remarks-analysis parameter is used.

The code was introduced by Tyler Nowicki in 2015:

commit e0f400feaa6b0f830cbbc288d0858c506046357b
Author: Tyler Nowicki <[e-mail]>
Date: Thu Aug 27 01:02:04 2015 +0000

Improved printing of analysis diagnostics in the loop vectorizer.

This patch ensures that every analysis diagnostic produced by the vectorizer
will be printed if the loop has a vectorization hint on it. The condition has
also been improved to prevent printing when a disabling hint is specified.

[hsaito]

Aha, that was a "hacky" way to get "loop contains a switch statement" along with the warning. I see. I suppose we can't blindly use LV_NAME, then.
I then suppose some tests (like pr38800.ll) didn't even need -pass-remarks-missed flag (which is incorrectly used, I think).

We better add some comments in vectorizeAnalysisPassName().

[psamolysov]

@rengolin @hsaito Well, I've restored the behavior: the method vectorizeAnalysisPassName has been taken into account again. I've reverted the tests also, all the tests in LoopVectorize pass successfully.

[rengolin]

Better this way, let's keep the changes contained to one per patch. If there's interest to change that behaviour or not, it should not hold this patch, which looks good to me now. Thanks!

[psamolysov]

@rengolin @hsaito I understand you were busy during the version 9 pre-releasing. But if you have time and the diff looks good for you, could you land it? Thank you.

[hsaito]

In D62997#1614288, @psamolysov wrote:

@rengolin @hsaito I understand you were busy during the version 9 pre-releasing. But if you have time and the diff looks good for you, could you land it? Thank you.

I can land this today.

[hsaito]

In D62997#1614330, @hsaito wrote:

In D62997#1614288, @psamolysov wrote:

@rengolin @hsaito I understand you were busy during the version 9 pre-releasing. But if you have time and the diff looks good for you, could you land it? Thank you.

I can land this today.

Done.

Sending include/llvm/Transforms/Vectorize/LoopVectorizationLegality.h
Sending include/llvm/Transforms/Vectorize/LoopVectorize.h
Sending lib/Transforms/Vectorize/LoopVectorizationLegality.cpp
Sending lib/Transforms/Vectorize/LoopVectorize.cpp
Adding test/Transforms/LoopVectorize/nofloat-report.ll
Transmitting file data .....
Committed revision 367980.

[hsaito]

Buildbot failures reported so far. Just FYI. I don't think any actions from this commit is needed.

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/7688 --- I don't think the failure is related to this commit.
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/7038 --- seems to be the same issue as above
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/22705 --- just flaky? subsequent builds are fine.

[rengolin]

Nope, Asan failures from the sanitizer commit.

[hsaito]

In D62997#1617197, @rengolin wrote:

Nope, Asan failures from the sanitizer commit.

Thanks.

[psamolysov]

@hsaito thank you for the landing and information.

llvm/include/llvm/Transforms/Vectorize/LoopVectorizationLegality.h

 
 #include "llvm/ADT/MapVector.h"
 #include "llvm/Analysis/LoopAccessAnalysis.h"
 #include "llvm/Analysis/OptimizationRemarkEmitter.h"
 #include "llvm/Transforms/Utils/LoopUtils.h"
 
 namespace llvm {
 
-/// Create an analysis remark that explains why vectorization failed
-///
-/// \p PassName is the name of the pass (e.g. can be AlwaysPrint).  \p
-/// RemarkName is the identifier for the remark.  If \p I is passed it is an
-/// instruction that prevents vectorization.  Otherwise \p TheLoop is used for
-/// the location of the remark.  \return the remark object that can be
-/// streamed to.
-OptimizationRemarkAnalysis createLVMissedAnalysis(const char *PassName,
-                                                  StringRef RemarkName,
-                                                  Loop *TheLoop,
-                                                  Instruction *I = nullptr);
+/// Reports a vectorization failure: print \p DebugMsg for debugging
+/// purposes along with the corresponding optimization remark \p RemarkName.
+/// If \p I is passed, it is an instruction that prevents vectorization.
+/// Otherwise, the loop \p TheLoop is used for the location of the remark.
+void reportVectorizationFailure(const StringRef DebugMsg,
+    const StringRef OREMsg, const StringRef ORETag,const char *AnalysisPassName,
+    OptimizationRemarkEmitter *ORE, Loop *TheLoop, Instruction *I = nullptr);
 
 /// Utility class for getting and setting loop vectorizer hints in the form
 /// of loop metadata.
 /// This class keeps a number of loop annotations locally (as member variables)
 /// and can, upon request, write them back as metadata on the loop. It will
 /// initially scan the loop for existing metadata, and will update the local
 /// values based on information in the loop.
 /// We cannot write all values to metadata, as the mere presence of some info,

llvm/lib/Transforms/Vectorize/LoopVectorizationLegality.cpp

static cl::opt<unsigned> PragmaVectorizeSCEVCheckThreshold(
     cl::desc("The maximum number of SCEV checks allowed with a "
              "vectorize(enable) pragma"));
 
 /// Maximum vectorization interleave count.
 static const unsigned MaxInterleaveFactor = 16;
 
 namespace llvm {
 
+/// Write a record \p DebugMsg about vectorization failure to the debug
+/// output stream. If \p I is passed, it is an instruction that prevents
+/// vectorization.
 #ifndef NDEBUG
 static void debugVectorizationFailure(const StringRef DebugMsg,
     Instruction *I) {
   dbgs() << "LV: Not vectorizing: " << DebugMsg;
   if (I != nullptr)
     dbgs() << " " << *I;
   else
     dbgs() << '.';
   dbgs() << '\n';
 }
 #endif
 
-OptimizationRemarkAnalysis createLVMissedAnalysis(const char *PassName,
-                                                  StringRef RemarkName,
-                                                  Loop *TheLoop,
-                                                  Instruction *I) {
+/// Create an analysis remark that explains why vectorization failed
+///
+/// \p PassName is the name of the pass (e.g. can be AlwaysPrint).  \p
+/// RemarkName is the identifier for the remark.  If \p I is passed it is an
+/// instruction that prevents vectorization.  Otherwise \p TheLoop is used for
+/// the location of the remark.  \return the remark object that can be
+/// streamed to.
+static OptimizationRemarkAnalysis createLVMissedAnalysis(const char *PassName,
+    StringRef RemarkName, Loop *TheLoop, Instruction *I) {
   Value *CodeRegion = TheLoop->getHeader();
   DebugLoc DL = TheLoop->getStartLoc();
 
   if (I) {
     CodeRegion = I->getParent();
     // If there is no debug location attached to the instruction, revert back to
     // using the loop's.
     if (I->getDebugLoc())
       DL = I->getDebugLoc();
   }
 
   OptimizationRemarkAnalysis R(PassName, RemarkName, DL, CodeRegion);
   R << "loop not vectorized: ";
   return R;
 }
 
+void reportVectorizationFailure(const StringRef DebugMsg,
+    const StringRef OREMsg, const StringRef ORETag,
+    const char *AnalysisPassName, OptimizationRemarkEmitter *ORE,
+    Loop *TheLoop, Instruction *I) {
+  LLVM_DEBUG(debugVectorizationFailure(DebugMsg, I));
+  ORE->emit(createLVMissedAnalysis(AnalysisPassName, ORETag, TheLoop, I)
+                << OREMsg);
+}
+
 bool LoopVectorizeHints::Hint::validate(unsigned Val) {
   switch (Kind) {
   case HK_WIDTH:
     return isPowerOf2_32(Val) && Val <= VectorizerParams::MaxVectorWidth;
   case HK_UNROLL:
     return isPowerOf2_32(Val) && Val <= MaxInterleaveFactor;
   case HK_FORCE:
     return (Val <= 1);

 
 bool LoopVectorizationLegality::isUniform(Value *V) {
   return LAI->isUniform(V);
 }
 
 void LoopVectorizationLegality::reportVectorizationFailure(
     const StringRef DebugMsg, const StringRef OREMsg,
     const StringRef ORETag, Instruction *I) const {
-  LLVM_DEBUG(debugVectorizationFailure(DebugMsg, I));
-  ORE->emit(createLVMissedAnalysis(Hints->vectorizeAnalysisPassName(),
-      ORETag, TheLoop, I) << OREMsg);
+  ::reportVectorizationFailure(DebugMsg, OREMsg, ORETag,
+      Hints->vectorizeAnalysisPassName(), ORE, TheLoop, I);
 }
 
 bool LoopVectorizationLegality::canVectorizeOuterLoop() {
   assert(!TheLoop->empty() && "We are not vectorizing an outer loop.");
   // Store the result and return it at the end instead of exiting early, in case
   // allowExtraAnalysis is used to report multiple reasons for not vectorizing.
   bool Result = true;
   bool DoExtraAnalysis = ORE->allowExtraAnalysis(DEBUG_TYPE);

llvm/lib/Transforms/Vectorize/LoopVectorize.cpp

private:
   /// Returns whether the instruction is a load or store and will be a emitted
   /// as a vector operation.
   bool isConsecutiveLoadOrStore(Instruction *I);
 
   /// Returns true if an artificially high cost for emulated masked memrefs
   /// should be used.
   bool useEmulatedMaskMemRefHack(Instruction *I);
 
-  /// Create an analysis remark that explains why vectorization failed
-  ///
-  /// \p RemarkName is the identifier for the remark.  \return the remark object
-  /// that can be streamed to.
-  OptimizationRemarkAnalysis createMissedAnalysis(StringRef RemarkName) {
-    return createLVMissedAnalysis(Hints->vectorizeAnalysisPassName(),
-                                  RemarkName, TheLoop);
+  /// Reports a vectorization illegality: print \p DebugMsg for debugging
+  /// purposes along with the corresponding optimization remark \p RemarkName.
+  /// If \p I is passed it is an instruction that prevents vectorization.
+  /// Otherwise the loop is used for the location of the remark.
+  void reportVectorizationFailure(const StringRef DebugMsg,
+      const StringRef OREMsg, const StringRef ORETag,
+      Instruction *I = nullptr) const {
+    ::reportVectorizationFailure(DebugMsg, OREMsg, ORETag,
+        Hints->vectorizeAnalysisPassName(), ORE, TheLoop, I);
   }
 
   /// Map of scalar integer values to the smallest bitwidth they can be legally
   /// represented as. The vector equivalents of these values should be truncated
   /// to this type.
   MapVector<Instruction *, uint64_t> MinBWs;
 
   /// A type representing the costs for instructions if they were to be
void LoopVectorizationCostModel::collectLoopUniforms(unsigned VF) {
 
   Uniforms[VF].insert(Worklist.begin(), Worklist.end());
 }
 
 Optional<unsigned> LoopVectorizationCostModel::computeMaxVF(bool OptForSize) {
   if (Legal->getRuntimePointerChecking()->Need && TTI.hasBranchDivergence()) {
     // TODO: It may by useful to do since it's still likely to be dynamically
     // uniform if the target can skip.
-    LLVM_DEBUG(
-        dbgs() << "LV: Not inserting runtime ptr check for divergent target");
-
-    ORE->emit(
-      createMissedAnalysis("CantVersionLoopWithDivergentTarget")
-      << "runtime pointer checks needed. Not enabled for divergent target");
-
+    reportVectorizationFailure(
+        "Not inserting runtime ptr check for divergent target",
+        "runtime pointer checks needed. Not enabled for divergent target",
+        "CantVersionLoopWithDivergentTarget");
     return None;
   }
 
   unsigned TC = PSE.getSE()->getSmallConstantTripCount(TheLoop);
   if (!OptForSize) // Remaining checks deal with scalar loop when OptForSize.
     return computeFeasibleMaxVF(OptForSize, TC);
 
   if (Legal->getRuntimePointerChecking()->Need) {
-    ORE->emit(createMissedAnalysis("CantVersionLoopWithOptForSize")
-              << "runtime pointer checks needed. Enable vectorization of this "
-                 "loop with '#pragma clang loop vectorize(enable)' when "
-                 "compiling with -Os/-Oz");
-    LLVM_DEBUG(
-        dbgs()
-        << "LV: Aborting. Runtime ptr check is required with -Os/-Oz.\n");
+    reportVectorizationFailure("Runtime ptr check is required with -Os/-Oz",
+        "runtime pointer checks needed. Enable vectorization of this "
+        "compiling with -Os/-Oz", "CantVersionLoopWithOptForSize");
     return None;
   }
 
   if (!PSE.getUnionPredicate().getPredicates().empty()) {
-    ORE->emit(createMissedAnalysis("CantVersionLoopWithOptForSize")
-              << "runtime SCEV checks needed. Enable vectorization of this "
-                 "loop with '#pragma clang loop vectorize(enable)' when "
-                 "compiling with -Os/-Oz");
-    LLVM_DEBUG(
-        dbgs()
-        << "LV: Aborting. Runtime SCEV check is required with -Os/-Oz.\n");
+    reportVectorizationFailure("Runtime SCEV check is required with -Os/-Oz",
+        "runtime SCEV checks needed. Enable vectorization of this "
+        "compiling with -Os/-Oz", "CantVersionLoopWithOptForSize");
     return None;
   }
 
   // FIXME: Avoid specializing for stride==1 instead of bailing out.
   if (!Legal->getLAI()->getSymbolicStrides().empty()) {
-    ORE->emit(createMissedAnalysis("CantVersionLoopWithOptForSize")
-              << "runtime stride == 1 checks needed. Enable vectorization of "
-                 "this loop with '#pragma clang loop vectorize(enable)' when "
-                 "compiling with -Os/-Oz");
-    LLVM_DEBUG(
-        dbgs()
-        << "LV: Aborting. Runtime stride check is required with -Os/-Oz.\n");
+    reportVectorizationFailure("Runtime stride check is required with -Os/-Oz",
+        "runtime stride == 1 checks needed. Enable vectorization of "
+        "compiling with -Os/-Oz", "CantVersionLoopWithOptForSize");
     return None;
   }
 
   // If we optimize the program for size, avoid creating the tail loop.
   LLVM_DEBUG(dbgs() << "LV: Found trip count: " << TC << '\n');
 
   if (TC == 1) {
-    ORE->emit(createMissedAnalysis("SingleIterationLoop")
-              << "loop trip count is one, irrelevant for vectorization");
-    LLVM_DEBUG(dbgs() << "LV: Aborting, single iteration (non) loop.\n");
+    reportVectorizationFailure("Single iteration (non) loop",
+        "loop trip count is one, irrelevant for vectorization",
+        "SingleIterationLoop");
     return None;
   }
 
   // Record that scalar epilogue is not allowed.
   LLVM_DEBUG(dbgs() << "LV: Not allowing scalar epilogue due to -Os/-Oz.\n");
 
   IsScalarEpilogueAllowed = !OptForSize;
 
Optional<unsigned> LoopVectorizationCostModel::computeMaxVF(bool OptForSize) {
   // by masking.
   // FIXME: look for a smaller MaxVF that does divide TC rather than masking.
   if (Legal->canFoldTailByMasking()) {
     FoldTailByMasking = true;
     return MaxVF;
   }
 
   if (TC == 0) {
-    ORE->emit(
-        createMissedAnalysis("UnknownLoopCountComplexCFG")
-        << "unable to calculate the loop count due to complex control flow");
+    reportVectorizationFailure(
+        "Unable to calculate the loop count due to complex control flow",
+        "unable to calculate the loop count due to complex control flow",
+        "UnknownLoopCountComplexCFG");
     return None;
   }
 
-  ORE->emit(createMissedAnalysis("NoTailLoopWithOptForSize")
-            << "cannot optimize for size and vectorize at the same time. "
-               "Enable vectorization of this loop with '#pragma clang loop "
-               "vectorize(enable)' when compiling with -Os/-Oz");
+  reportVectorizationFailure(
+      "Cannot optimize for size and vectorize at the same time.",
+      "cannot optimize for size and vectorize at the same time. "
+      "vectorize(enable)' when compiling with -Os/-Oz",
+      "NoTailLoopWithOptForSize");
   return None;
 }
 
 unsigned
 LoopVectorizationCostModel::computeFeasibleMaxVF(bool OptForSize,
                                                  unsigned ConstTripCount) {
   MinBWs = computeMinimumValueSizes(TheLoop->getBlocks(), *DB, &TTI);
   unsigned SmallestType, WidestType;
for (unsigned i = 2; i <= MaxVF; i *= 2) {
     }
     if (VectorCost < Cost) {
       Cost = VectorCost;
       Width = i;
     }
   }
 
   if (!EnableCondStoresVectorization && NumPredStores) {
-    ORE->emit(createMissedAnalysis("ConditionalStore")
-              << "store that is conditionally executed prevents vectorization");
-    LLVM_DEBUG(
-        dbgs() << "LV: No vectorization. There are conditional stores.\n");
+    reportVectorizationFailure("There are conditional stores.",
+        "store that is conditionally executed prevents vectorization",
+        "ConditionalStore");
     Width = 1;
     Cost = ScalarCost;
   }
 
   LLVM_DEBUG(if (ForceVectorization && Width > 1 && Cost >= ScalarCost) dbgs()
              << "LV: Vectorization seems to be not beneficial, "
              << "but was forced by a user.\n");
   LLVM_DEBUG(dbgs() << "LV: Selecting VF: " << Width << ".\n");
if (HasExpectedTC && ExpectedTC < TinyTripCountVectorThreshold) {
     }
   }
 
   // Check the function attributes to see if implicit floats are allowed.
   // FIXME: This check doesn't seem possibly correct -- what if the loop is
   // an integer loop and the vector instructions selected are purely integer
   // vector instructions?
   if (F->hasFnAttribute(Attribute::NoImplicitFloat)) {
-    LLVM_DEBUG(dbgs() << "LV: Can't vectorize when the NoImplicitFloat"
-                         "attribute is used.\n");
-    ORE->emit(createLVMissedAnalysis(Hints.vectorizeAnalysisPassName(),
-                                     "NoImplicitFloat", L)
-              << "loop not vectorized due to NoImplicitFloat attribute");
+    ::reportVectorizationFailure(
+        "Can't vectorize when the NoImplicitFloat attribute is used",
+        "loop not vectorized due to NoImplicitFloat attribute",
+        "NoImplicitFloat", Hints.vectorizeAnalysisPassName(), ORE, L);
     Hints.emitRemarkWithHints();
     return false;
   }
 
   // Check if the target supports potentially unsafe FP vectorization.
   // FIXME: Add a check for the type of safety issue (denormal, signaling)
   // for the target we're vectorizing for, to make sure none of the
   // additional fp-math flags can help.
   if (Hints.isPotentiallyUnsafe() &&
       TTI->isFPVectorizationPotentiallyUnsafe()) {
-    LLVM_DEBUG(
-        dbgs() << "LV: Potentially unsafe FP op prevents vectorization.\n");
-    ORE->emit(
-        createLVMissedAnalysis(Hints.vectorizeAnalysisPassName(), "UnsafeFP", L)
-        << "loop not vectorized due to unsafe FP support.");
+    ::reportVectorizationFailure(
+        "Potentially unsafe FP op prevents vectorization",
+        "loop not vectorized due to unsafe FP support.",
+        "UnsafeFP", Hints.vectorizeAnalysisPassName(), ORE, L);
     Hints.emitRemarkWithHints();
     return false;
   }
 
   bool UseInterleaved = TTI->enableInterleavedAccessVectorization();
   InterleavedAccessInfo IAI(PSE, L, DT, LI, LVL.getLAI());
 
   // If an override option has been passed in for interleaved accesses, use it.

llvm/test/Transforms/LoopVectorize/nofloat-report.ll

+; REQUIRES: asserts
+; RUN: opt -loop-vectorize -force-vector-interleave=1 -force-vector-width=4 -debug-only=loop-vectorize\
+; RUN:     -disable-output -S %s 2>&1 | FileCheck %s
+
+; Make sure that we report about not vectorizing functions with 'noimplicitfloat' attributes
+
+target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
+
+@a = common global [2048 x i32] zeroinitializer, align 16
+
+; CHECK: LV: Not vectorizing: Can't vectorize when the NoImplicitFloat attribute is used
+define void @example_nofloat() noimplicitfloat { ;           <--------- "noimplicitfloat" attribute here!
+  br label %1
+
+; <label>:1                                       ; preds = %1, %0
+  %indvars.iv = phi i64 [ 0, %0 ], [ %indvars.iv.next, %1 ]
+  %2 = getelementptr inbounds [2048 x i32], [2048 x i32]* @a, i64 0, i64 %indvars.iv
+  %3 = trunc i64 %indvars.iv to i32
+  store i32 %3, i32* %2, align 4
+  %indvars.iv.next = add i64 %indvars.iv, 1
+  %lftr.wideiv = trunc i64 %indvars.iv.next to i32
+  %exitcond = icmp eq i32 %lftr.wideiv, 1024
+  br i1 %exitcond, label %4, label %1
+
+; <label>:4                                       ; preds = %1
+  ret void
+}