Check the bool value of the attribute in getOptionalBoolLoopAttribute
not just its existance. If the llvm.loop.vectorize exists, but is set to false, hasVectorizeTransformation would return TM_ForcedByUser instead of TM_SuppressedByUser.
This eliminates the warning noise generated when vectorization is explicitly disabled.
Details
- Reviewers
Meinersbur hfinkel dmgreen - Commits
- rGa9a9c27e1c25: Merging r352555: --------------------------------------------------------------…
rL353167: Merging r352555:
rGf9027e554a62: Check bool attribute value in getOptionalBoolLoopAttribute.
rL352555: Check bool attribute value in getOptionalBoolLoopAttribute.
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 27468 Build 27467: arc lint + arc unit
Event Timeline
The check hasVectorizeTransformation(L) in front checks whether vectorization is forced by the user. It is not necessary that the user also fixes the simd width/interleave count. Hence, the warning is valid in this case. It is the same behavior as before rL348944 (which I tried to replicate).
test/Transforms/LoopVectorize/X86/vectorization-remarks-missed.ll | ||
---|---|---|
36 ↗ | (On Diff #183626) | Assuming the comment above accurately describes the IR, why do you think the warning should not be emitted? |
Mistaken source of the noise, the bug I was chasing was in getOptionalBoolLoopAttribute, called by hasVectorizeTransformation(L).
If the llvm.loop.vectorize exists, but is set to false, hasVectorizeTransformation would return TM_ForcedByUser instead of TM_SuppressedByUser.
Thanks for catching this. Looks like I did not think about calling getZExtValue on ConstantInt, but didn't notive because ConstantInt* converts to bool implicitly.
It would be good if you could add the noise warning example as a test case.
Added a test that show-cases the issue resolved by this patch.
The test is a duplicate of an existing LoopVectorize tests with the metadata set to false.