This is an archive of the discontinued LLVM Phabricator instance.

[Polly]Fix code generation bug with Polly vectorizer
Needs ReviewPublic

Authored by annanay25 on May 9 2017, 9:11 AM.

Details

Summary

This patch fixes bug - https://bugs.llvm.org/show_bug.cgi?id=32533

Bug description:
In VectorBlockGenerator::copyStmt() the argument Stmt does not satisfy the assertion Stmt.isBasicBlock() - which from its definition - Returns true if the statement represents a single basic block.

Diff Detail

Event Timeline

annanay25 created this revision.May 9 2017, 9:11 AM
Meinersbur edited edge metadata.May 10 2017, 4:40 AM

Thank you for the patch. Some general hints:

  • Try to run ninja check-polly (or make check-polly). It will complain about formatting (like missing spaces). You can automatically correct them using ninja polly-update-format
  • Please add a test case.
  • Please add context to the diff. See: http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
  • Please add "llvm-commits" and "pollydev" to the subscribers. Also prefix the title with "[Polly]"
lib/CodeGen/IslNodeBuilder.cpp
362–363

If Stmt->isRegionStmt(), these are not used. createUser does the same work again.

365

We usually do not use braces around single statements.

366

Are you sure it is that simple? VectorBlockGenerator::generate generates code to process VectorWidth elements at once. create, which will call createUser, only code to process a single element.

annanay25 retitled this revision from Fix code generation bug with Polly vectorizer to [Polly]Fix code generation bug with Polly vectorizer.May 15 2017, 12:13 AM
annanay25 added a subscriber: pollydev.

I have overlooked some details, I will go over the code again.

The cause of the bug is that VectorBlockGenerator::generate() only accepts a single basic block in the Stmt region. Hence,

if ( Stmt->isRegionStmt() )
  // Do some action
else
  VectorBlockGenerator::generate(BlockGen, *Stmt, VLTS, S, NewAccesses);

is one solution. Working out the details for the if part.

Thanks,
Annanay

Can we just fall back to generating non-vectorized code in these cases. This code path certainly should not break, but as we do not use the Polly vectorizer by default, it is likely not worth spending time on optimizing execution time performance before we find a test case where this is really useful.

annanay25 added a comment.EditedMay 15 2017, 1:38 AM

Yes sir, in this particular bug we are however, explicitly calling polly's vectorizer.

opt  -polly-process-unprofitable  -polly-remarks-minimal  -polly-vectorizer=polly -polly-codegen -S constants_0.ll

The fix that I suggested above is a strict no, it breaks too many test cases:

Failing Tests (24):
    Polly :: Isl/CodeGen/MemAccess/simple_analyze.ll
    Polly :: Isl/CodeGen/MemAccess/simple_stride_test.ll
    Polly :: Isl/CodeGen/invariant_load_hoist_alignment.ll
    Polly :: Isl/CodeGen/simple_vec_assign_scalar.ll
    Polly :: Isl/CodeGen/simple_vec_assign_scalar_2.ll
    Polly :: Isl/CodeGen/simple_vec_call.ll
    Polly :: Isl/CodeGen/simple_vec_call_2.ll
    Polly :: Isl/CodeGen/simple_vec_cast.ll
    Polly :: Isl/CodeGen/simple_vec_const.ll
    Polly :: Isl/CodeGen/simple_vec_large_width.ll
    Polly :: Isl/CodeGen/simple_vec_ptr_ptr_ty.ll
    Polly :: Isl/CodeGen/simple_vec_stride_negative_one.ll
    Polly :: Isl/CodeGen/simple_vec_stride_one.ll
    Polly :: Isl/CodeGen/simple_vec_stride_x.ll
    Polly :: Isl/CodeGen/simple_vec_strides_multidim.ll
    Polly :: Isl/CodeGen/simple_vec_two_stmts.ll
    Polly :: ScheduleOptimizer/pattern-matching-based-opts_3.ll
    Polly :: ScopInfo/phi-in-non-affine-region.ll
    Polly :: ScopInfo/stride_detection.ll
    Polly :: ScopInfo/user_provided_assumptions-in-bb-unsigned.ll
    Polly :: ScopInfo/user_provided_assumptions.ll
    Polly :: ScopInfo/user_provided_assumptions_2.ll
    Polly :: ScopInfo/user_provided_assumptions_3.ll
    Polly :: ScopInfo/user_provided_non_dominating_assumptions.ll

  Expected Passes    : 719
  Expected Failures  : 11
  Unsupported Tests  : 35
  Unexpected Failures: 24

There is no guarantee that every statement must be vectorized. The only requirement is that we should not crash or assert. Feel free to add vectorization support for regions, but my advice is to delay further support until we have evidence that this could speed up performance. ;-)

@grosser sure thing sir, thanks!

annanay25 updated this revision to Diff 99133.May 16 2017, 6:30 AM
annanay25 added a reviewer: grosser.

This code falls back to generating scalar code when isl_ast_node_user is found to be a Region.

List of failed tests -

Failing Tests (7):
    Polly :: ScheduleOptimizer/pattern-matching-based-opts_3.ll
    Polly :: ScopInfo/phi-in-non-affine-region.ll
    Polly :: ScopInfo/user_provided_assumptions-in-bb-unsigned.ll
    Polly :: ScopInfo/user_provided_assumptions.ll
    Polly :: ScopInfo/user_provided_assumptions_2.ll
    Polly :: ScopInfo/user_provided_assumptions_3.ll
    Polly :: ScopInfo/user_provided_non_dominating_assumptions.ll

  Expected Passes    : 737
  Expected Failures  : 11
  Unsupported Tests  : 35
  Unexpected Failures: 7

I added a check in D33255 that tests whether some code-to-be-vectorized contains a partial accesses (which it cannot vectorize). You could take a similar approach for region statements.