Problems related to mismatching executors

[gflegar]

Some operations on operators on Ginkgo assume that the executors of all arguments are the same. This does not have to be true, and with the addition of gko::make_temporary_clone helper can usually be solved easily.

BLAS-1 operations on dense matrices are an example of this problem.

[gflegar]

@tcojean this is not needed for the 1.0.0 release? This can break Ginkgo in a very unpleasant way, without any hint to the user about what went wrong...

[tcojean]

I agree it would be nice to have this. I will add it to the milestone, we should see who can take it.

[gflegar]

It should be a very straightforward process (just needs a bit of time): someone should go through all of Ginkgo's public methods, and check the implementation of the ones that have a LinOp (or LinOp subclass) instance as a parameter. If the implementation calls a kernel and passes this parameter to it, without doing anything special to ensure that the executor the kernel is called on matches with the executor of the LinOp instance, instead of passing the original instance, a gko::temporary_clone of it (with the lifetime of the public method's implementation) should be passed instead.

[gflegar]

Here is an example of correct executor consistency handling via temporary clones.