Another consideration is that a cudf::column_view could be sliced which means it has a non-zero offset and represents only a partial view of the underlying data. This is handy in partitioning large columns with zero-copying.
So I think the jit::column_device_view would need to be able to handle this kind of input.

I've added that now

As we are repeating the same code, I've created a follow-up issue to refactor the existing column_device_view for use in device code: #18229.

I don't think we should be using mutable_column_device_view for wrapping non mutable inputs.

To avoid duplicating functionality in this PR that will eventually be made redundant, I've gone ahead and implemented #18229 along with this PR.
So I've extracted column_device_view's core functionality into a basic_column_device_view that can now be used with JITify kernels.

It would be great to have a brown bag session to discuss the potential solution with the team. Instead of introducing a new basic_column_device_view, I personally find that moving the host APIs declared in the existing column_device_view.cuh header to a new header provides a cleaner solution.

What about the static methods?
and the methods that contain host code? like thrust and rmm?
If we move those, we'd also have to update all the call-sites, making this PR larger.

What about the static methods?

These are the host functions I mentioned that could be moved to a separate C++ header. Instead of being static members, could we convert them into a factory function, like make_column_device_view? Ideally, CUDA headers should contain declarations for both host-device and device-only APIs. If it's a host-only API, a C++ header is likely the best place for it.

and the methods that contain host code? like thrust and rmm?

That’s the part I’m missing, which is why I’m asking for a brown bag session. What kind of host code is prohibited by JIT? Does it have to be device-only, or is host-device code also fine? I’m asking because cuda::std:: utilities are host-device compatible, and they seem to work with JIT. Thrust utilities used in this header, like pair and fancy iterators, are also host-device, so I’m not sure why they cannot be used in JIT code. As for the RMM usage, they all come from host-only APIs as I noticed, so I assume it shouldn’t be an issue after we move them into a separate C++ header.

I did not really expect you go and refactor everything for this PR. I was more expecting just create a jit::column_device_view to match the jit::mutable_column_device_view and do the refactoring later in the follow-up PR.

I did not really expect you go and refactor everything for this PR. I was more expecting just create a jit::column_device_view to match the jit::mutable_column_device_view and do the refactoring later in the follow-up PR.

Yes, I'm sorry about that, I wanted to keep the changeset minimal as well, but to have the jit::column_view and jit::mutable_column_view we'll end up writing a lot of duplicate code just to throw them away soon, which only became evident to me after adding jit::mutable_column_view. I was initially hesitant to refactor it in this PR to keep the changeset small, but I'm open to setting up a meeting to discuss the changes.

That’s the part I’m missing, which is why I’m asking for a brown bag session. What kind of host code is prohibited by JIT? Does it have to be device-only, or is host-device code also fine? I’m asking because cuda::std:: utilities are host-device compatible, and they seem to work with JIT. Thrust utilities used in this header, like pair and fancy iterators, are also host-device, so I’m not sure why they cannot be used in JIT code.

Yes, it has to be device-only code and headers. This means we can't include system headers like thrust does, even if the contents aren't used or called. I described the problem in this issue: #17399.

As for the RMM usage, they all come from host-only APIs as I noticed, so I assume it shouldn’t be an issue after we move them into a separate C++ header.

If @davidwendt agrees that they should be moved in this PR, I'd prefer to move them outside the classes as well.

I still have questions about JIT compilation, but I’ll pause here to focus on making progress. I agree with David that the initial goal is to introduce a lightweight column device view specifically for JIT. Having duplicates is fine for now, as it helps narrow the scope for the final cleanup.