Open 9il opened 7 years ago
Definitely.
@compute(CompileFor.hostAndDevice)
to work on both the host and device code however will require that the module of origin be marked @compute(CompileFor.hostAndDevice) to work on both the host and device
Do you mean mir.ndslice should be marked?
yes. I think it would be good to have a module (probably in dcompute) that imports all the relevant dcompute symbols from ldc.attributes
and ldc.dcomputetypes
if version = LDC_DCompute and otherwise sets up proxies for the symbols so you can still compile without a dcompute enabled ldc.
yes. I think it would be good to have a module (probably in dcompute) that imports all the relevant dcompute symbols from ldc.attributes and ldc.dcomputetypes if version = LDC_DCompute and otherwise sets up proxies for the symbols so you can still compile without a dcompute enabled ldc.
@thewilsonator Why not to allow any generic code to be instantiated in a marked module?
?? Not sure what you mean. Any modules, regardless of its @compute
'ness, can have templates. The section you quoted would be for enabling building with a non-dcompute enabled compiler (e.g. old LDC and DMD/GDC)
I mean that I do not understand why ndslice should be marked if it is completely generic. If we call a generic function from kernel function it can be automatically determinated that generic should be compiled for kernel
Actually that might work. I'm not quite sure how template instances end up in a given module's symbol table, but if it does because it is referenced by that module, then the code would suggest that that would work.
We would still need @compute
modules that reference them, though.
Can we use library @nothrow @nogc generic code in kernels. For example
Slice!(Contiguous, [1], GlobalPointer!T)
and ndslice topology?