LGTM. Btw can we also make codegen return results? When I add RPC later, I will have to return an error if the RPC parameter type is not something that we support. Thanks.
Sure, I am now…
LGTM. Btw can we also make codegen return results? When I add RPC later, I will have to return an error if the RPC parameter type is not something that we support. Thanks.
Just wondering: Do we really need thhe IRRT prefix? The symbol names are super long and I think __nac3 prefix is enough?
Using the old compiler with this firmware would have issue due to differences in handling the except clause: the old one would emit a name but this patch expects a null pointer.
And what…
Should be used together with https://github.com/m-labs/artiq/tree/landingpad
The compiler change: Yes, it should be. The original firmware will run the clause anyway during unwind, so the…
Yes another way is to use the
double**int -> doublellvm intrinsic (llvm does not provideint**int -> intintrinsic..). And to address this bug…
and why can't we use the intrinsic? is it removed in newer versions?
you can print the IR and run it through opt to see if it can fold well.
Sorry forgot that this is a separate function call. If so it should be fine. I guess you fast path can be removed too.
Well this is actually unsafe. We may have u64 length pointer for 64 bits target... Maybe you can make a temporary integer, take its address and store it back? I don't think we will ever do something that big so it should be fine. I think LLVM should be able to optimize this for 32 bits target.
I guess you can make this a special case of the next case. Just ignore the step if src_len == 0 and avoid the first memcpy but keep the second.
You should use memcpy, which is usually faster than memmove. memmove should only be used when the buffers overlap, i.e. when you shift the remaining elements in the list.