LGTM – it's a pretty typo, and the logic is required (I have a similar patch for upstream ARTIQ on x86_64 [as part of my on-host core device emulator branch](https://github.com/dnadlinger/artiq/c…
(apologies, clicked the "Comment and Close" button by mistake)
Effectively the array would be represented as NDArray[dtype, ndims] in the type system, where ndims is a const-generic argument specifying the number of dimensions.
Yep, this then matches my…
Effectively the array would be represented as NDArray[dtype, ndims] in the type system, where ndims is a const-generic argument specifying the number of dimensions.
Yep, this then matches my…
In actual scientific code using NumPy/SciPy, reshaping between arrays with different numbers of dimensions is reasonably common. While IIRC not currently supported in artiq.compiler, staying…
Did you discard requiring the number of dimensions to be known at compile-time (like in the current compiler) for some particular reason?
This struck me as the most suitable tradeoff between…
IIRC this just adds more complexity, as i1 is still used for IR-level boolean operations (comparisons, select, etc.). The clearest solution re complexity/confusion seems to be to just insist…
Yep, using i8 as the "storage type" for bool is, unfortunately, the way to go; this is the standard approach in other compilers.
Yes; seems like this might potentially be a stack lifetime issue that is just masked by more aggressive optimisations.
For debugging IR issues, using the standalone LLVM tools to run the…
df4988c774b7095c6cc71dcccace2f079a1ff805 (for the RPC alignment issues at least).
