Support for general pointers and function pointers and porting to latest

[raldone01]

There is prior art to this:
https://www.youtube.com/watch?v=bRyculBbjMA
https://xol.io/blah/introducing-vcc/
https://github.com/shady-gang/shady
Interesting related blogs: https://xol.io/blah/
TLDR: They implemented general pointers (including casts), function pointers and a stack in spirv with acceptable performance.

I have been poking around in this code base quite a lot yesterday.
It would be very nice to support niches and dynamic memcpy (as fallback).

I also started porting rust gpu to the latest nightly for fun and hit a snag here:
code --goto /home/main/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/cmp.rs:43:14

#[inline]
fn as_underlying(x: ControlFlow<bool>) -> u8 {
    // SAFETY: This will only compile if `bool` and `ControlFlow<bool>` have the same
    // size (which isn't guaranteed but this is libcore). Because they have the same
    // size, it's a niched implementation, which in one byte means there can't be
    // any uninitialized memory. The callers then only check for `0` or `1` from this,
    // which must necessarily match the `Break` variant, and we're fine no matter
    // what ends up getting picked as the value representing `Continue(())`.
    unsafe { crate::mem::transmute(x) }
}

This is caused by disabling niches here:

providers.layout_of = |tcx, key| {
        let TyAndLayout { ty, mut layout } =
            (rustc_interface::DEFAULT_QUERY_PROVIDERS.layout_of)(tcx, key)?;

        #[allow(clippy::match_like_matches_macro)]
        let hide_niche = match ty.kind() {
            ty::Bool => true,
            _ => false,
        };

        if hide_niche {
            layout = tcx.mk_layout(LayoutData {
                largest_niche: None,
                ..clone_layout(layout.0.0)
            });
        }

        Ok(TyAndLayout { ty, layout })
    };

I got there because array::from_fn uses transmute_unchecked which is unimplemented. I believe the benefits of emulating real pointers and function pointers in spirv would be immense for rust gpu usage. Even if performance is bad I believe correctness/support is more important. When performance really matters users can optimize their code to avoid using the emulated memory/function pointers.

Also most hardware natively supports all these features anyways so the gpu driver spirv compilers will handle it somewhat performantly.

[LegNeato]

Thanks for the links! Interesting stuff.

For latest nightly, you can look at #249. The niche problem is unfortunate.

@eddyb is currently working on quasi-pointers (qptr).

See some WIPs:

https://github.com/LykenSol/rust-gpu/tree/ephemera/polaris-plus-rec-call-emu

https://github.com/LykenSol/rust-gpu-lodestar

https://github.com/LykenSol/spirt/tree/qptr-legalize

[raldone01]

Ahh thanks good to see that work is being done in that direction. I was a little worried that dynamic memcpy/generic pointers/function pointers weren't even on the roadmap.