[int_19h]

> I've been using it as an experimental backend for my language project with great results.

One annoyance that I've ran into when using Zig as a transpiler backend is the lack of unstructured goto. Many languages don't need that, but if you're dealing with the one that does, converting such code is non-trivial.

[olivia-banks]

Yeah, this is one of the bigger pain points (that and no dynamic stack allocation). I got around this by defining anonymous functions and then calling between them (using `@call(.always-tail, ...)` where possible to avoid stack-frame overhead).

Eventually, I restructured my IR to allow for more imperative code-generation, which I believe will lead to slightly better optimizations by the compiler.

[hansvm]

Labeled switches come pretty close. Is there a particular case you have in mind where they don't suffice?

[int_19h]

Ah, I wasn't aware of those - they seem to be a fairly recent addition? It definitely does simplify things for many common patterns, but not all, unfortunately; consider the case of a goto into the middle of a loop in C, or even something like Duff's Device.

[hansvm]

Yeah, it's fairly new. Maybe 0.14.1?

Those cases are definitely supported. Here's a reasonably faithful re-interpretation of Duff's device which generates the right assembly. If you'll take my word for it, code and assembly equivalent to goto in the middle of a loop body isn't an issue either. The only thing you're losing is the unreadable syntactic interleaving you can do in C.

    pub fn copy(T: type, noalias dst: []T, noalias src: []const T, unroll: comptime_int) void {
        if (unroll < 2)
            @compileError("No-op unrolls not supported");
        std.debug.assert(dst.len == src.len);
        std.debug.assert(dst.len > 0);

        var n: usize = (src.len + unroll - 1) / unroll;
        var i: usize = 0;
        duff: switch (src.len % unroll) {
            inline 0,2...unroll => |x| {
                dst[i] = src[i];
                i += 1;
                continue :duff (unroll + x - 1) % unroll;
            },
            inline 1 => {
                dst[i] = src[i];
                i += 1;
                n -= 1;
                if (n == 0)
                    break :duff;
                continue :duff 0;
            },
            else => unreachable,
        }
    }

[int_19h]

To remind, the original context was transpiling another language (with semantics that allows irreducible CFGs) to Zig, not just this one specific pattern. Yes, of course, for pretty much all practical code, there is going to be a better equivalent. But the transpiler doesn't get the benefit of only working with practical code - it has to deal with whatever the source language spec says is legal. So you need to come up with a generic solution to the entire class of problems presented. Which does exist - e.g. Relooper (https://mozakai.blogspot.com/2012/05/reloop-all-blocks.html) - but the point is that it is very much a non-trivial transformation, to the point where it might actually be easier to transpile to C or something else that has full-fledged goto that you can just use directly.

[hansvm]

Relooper goes the other direction though. We don't need to produce high-level control flow. For a transpilation-to-Zig use case the algorithm can be extremely dumb. Naively translate every loop (or any other control flow containing nontrivial internal gotos) into a labeled switch, then partition the bodies at each goto statement, making a new label for each such location.

The only thing you're really losing is that the goto is bounded by an enclosing function, but that's also the case in C, C++ and other languages written by non-masochists. From a developer ergonomics perspective you _might_ want a proper goto instead of having to rely on a clunky general-purpose transformation as described above (though I've yet to see that use case), but from a transpilation perspective it's extremely easy to just treat labeled switch as a bunch of gotos, replace other control flow with gotos, and lower an entire function into something that compiles optimally.