Refactor RetiledMatrix into Matrix

[msimberg]

Fixes #905.

I moved the creation of a RetiledMatrix into Matrix methods retiledSubPipeline{,Const} to mirror #898. Since the implementation is otherwise identical I've kept the "sub pipeline" name, but added retiled as a prefix (though the naming concerns from #898 apply here as well). I've removed the RetiledMatrix class and replaced it with Matrix. I've added an assertion to only allow retiling if the Matrix isn't already "retiled", i.e. if the tile size is the same as the block size. We can attempt to lift this restriction later if it's useful but I won't be doing that here. #923 also applies for retiled matrices and I'm not doing that in this PR either.

This should probably wait for #933 to be merged first, or maybe not...

[msimberg]

cscs-ci run

[msimberg]

cscs-ci run

[rasolca]

I have only a concern.
Algorithm implementations might not work with a retiled matrix as argument.

Therefore for each function that takes a matrix as argument we should either enhance the test and make sure it works or add an assertion.

Of course updating all the tests and fixing the algorithms does not belong to this PR.

Should we add an assertion at least in the public algorithms until they are tested and known to work?

Note: as a retiled matrix is now a Matrix, retiled of retiled will be needed. (e.g for complete functionality of #933)

[msimberg]

I have only a concern. Algorithm implementations might not work with a retiled matrix as argument.

Good point.

Therefore for each function that takes a matrix as argument we should either enhance the test and make sure it works or add an assertion.

Of course updating all the tests and fixing the algorithms does not belong to this PR.

Should we add an assertion at least in the public algorithms until they are tested and known to work?

I think that would be good. I will add that here.

Note: as a retiled matrix is now a Matrix, retiled of retiled will be needed. (e.g for complete functionality of #933)

Yeah, with the discussion in #933 I would include the redistributing copy to the list of algorithms above that currently require same block size and tile size. Then we can case by case relax the requirements/test what works with retiled matrices.

[msimberg]

@rasolca, @albestro see 0f5a091 for assertions on algorithms.

I added a helper function which I now called retiled(MatrixLike). I'm not super happy with the name, but it was better than unretiled. I could go for a more explicit equal_tile_and_block(_size) or something in that direction as well. Suggestions welcome.

[rasolca]

What about single_tile_per_block(matrix)?

[albestro]

I like both retiled and single_tile_per_block 😉 up to you. Thanks for adding the helper 👍🏻

[msimberg]

I'll go with single_tile_per_block. Thanks for the comments! Pushing soon...

[msimberg]

See f3ecb55 for the renaming to single_tile_per_block. Would you prefer if I update the preconditions in the docs from

@pre mat has equal tile and block sizes

to

@pre mat has a single tile per block

to match?

[rasolca]

See f3ecb55 for the renaming to single_tile_per_block. Would you prefer if I update the preconditions in the docs from

@pre mat has equal tile and block sizes

to

@pre mat has a single tile per block

to match?

No strong preference on my side.

[msimberg]

cscs-ci run