const subview of const view with compile time dimensions on Cuda backend

[dholladay00]

I have a const view View<const double*[N], LayoutRight, RandomAccess> a;
I try to assign a const view View<const double[N], LayoutRight, RandomAccess> b(subview(a,i,ALL())); which fails to compile.

If a is does not have const in it, then I do not receive a compile error (i.e. it compiles).

I have not tried auto, but that could work, would it yield the same thing (correct compile time dimensions, etc.)?

I have a MWE I can attach if need be.

This could be related to or an extension of issues #237, #257, and #258

[crtrott]

This should work, and is probably related to the general extension of that assignment stuff. Let me reproduce it and then we can take it from there. Auto will probably not give you the correct compile time thingy. Also the RandomAccess complicates things a bit (but still this should work). Can you try without RandomAccess?

[dholladay00]

Here is the MWE:

#include <Kokkos_Core.hpp>
#include <cstdio>

using Kokkos::parallel_for;
using Kokkos::MemoryTraits;
using Kokkos::RandomAccess;
using Kokkos::subview;
using Kokkos::ALL;
using Kokkos::LayoutRight;

typedef MemoryTraits< RandomAccess > RA;

template <class D, class ... P>
using View = Kokkos::View<D, P ... >;

int main (int argc, char* argv[]) {
  Kokkos::initialize(argc, argv);
  const int N = 10;
  // results in compile error
  View<const double*[4], LayoutRight, RA> A("A", N);

  // if use non-const instead, no compile error
  //View<double*[4], LayoutRight, RA> A("A", N);

  parallel_for (N, KOKKOS_LAMBDA (const int i)
  {
    View<const double[4], LayoutRight, RA> v(subview(A, i, ALL()));
  });

  Kokkos::finalize();
  return 0;
}

If you comment out the const A and un-comment the non-const A, then it compiles.

[dholladay00]

@crtrott, would commit bd85283 also help fix this issue?

[crtrott]

Not sure.

[crtrott]

Ok looking at your reproducer: this is actually expected and correct behaviour. You can not allocate a View of const data. The reasoning is that you could never change the data. You can't even default initialize it, so why would you ever create it?

The way to handle RandomAccess trait is to create a non-const view, and then assign it to a const one.

That said it looks like the RandomAccess property prevents subviews. The following code works without RA but doesn't with RA:

#include <Kokkos_Core.hpp>
#include <cstdio>

using Kokkos::parallel_for;
using Kokkos::MemoryTraits;
using Kokkos::RandomAccess;
using Kokkos::subview;
using Kokkos::ALL;
using Kokkos::LayoutRight;

typedef MemoryTraits< RandomAccess > RA;

template <class D, class ... P>
using View = Kokkos::View<D, P ... >;

int main (int argc, char* argv[]) {
  Kokkos::initialize(argc, argv);
  const int N = 10;
  // results in compile error
  View<double*[4], LayoutRight> A("A", N);
  View<const double*[4], LayoutRight,RA> c_A = A;


  parallel_for (N, KOKKOS_LAMBDA (const int i)
  {
    View<const double[4], LayoutRight, RA> v(subview(c_A, i, ALL()));
  });

  Kokkos::finalize();
  return 0;
}

[dholladay00]

Ah ok, so the best bet would probably be to have bigger view be non-const without any traits and assign const-ness and traits where the subview is constructed.

That makes sense, and I'm fairly certain I don't access the underlying data of the bigger view, it is only accessed from the subviews, so I don't think I should see a performance hit and it might decrease compile times?

I'll switch to that, and since we know that already works, I am ok with closing this issue.

[crtrott]

Not this can't be closed, because the RA trait has to be assigned outside of a parallel for to have any effect in Cuda (there is a texture object we need to create). That the above thing from me doesn't compile is a true bug and needs to be fixed. We also need a unit test for this, since it clearly is not tested. I identified the place in the code where it goes wrong, we just need to find a solution to fix it.

[crtrott]

The outstanding issue is actually the same as #385. I am close to have a fix.