Please Support Arbitrary Labels and Gotos.

I'd like to point out that I haven't been involved in the web assembly effort,
and I'm not maintaining any large or widely used compilers (just my own
toy-ish language, minor contributions to the QBE compiler backend, and an
internship on IBM's compiler team), but I ended up getting a bit ranty, and
was encouraged to share more widely.

So, while I'm a bit uncomfortable jumping in and suggesting major changes
to a project I haven't been working on... here goes:

My Complaints:

When I'm writing a compiler, the first thing that I'd do to with the high level
structure -- loops, if statements, and so on -- is validate them for semantics,
do type checking and so on. The second thing I do with them is just throw them
out, and flatten to basic blocks, and possibly to SSA form. In some other parts
of the compiler world, a popular format is continuation passing style. I'm not
an expert on compiling with continuation passing style, but it neither seems to
be a good fit for the loops and scoped blocks that web assembly seems to have
embraced.

I'd like to argue that a flatter, goto based format would be far more useful as
a target for compiler developers, and would not significantly hinder the
writing of a usable polyfill.

Personally, also I'm not a big fan of nested complex expressions. They're a bit
clunkier to consume, especially if inner nodes can have side effects, but I
don't strongly object to them as a compiler implementer -- The web assembly
JIT can consume them, I can ignore them and generate the instructions that map
to my IR. They don't make me want to flip tables.

The bigger problem comes down to loops, blocks, and other syntactic elements
that, as an optimizing compiler writer, you try very hard to represent as a
graph with branches representing edges; The explicit control flow constructs
are a hindrance. Reconstructing them from the graph once you've actually done
the optimizations you want is certainly possible, but it's quite a bit of
complexity to work around a more complex format. And that annoys me: Both the
producer and the consumer are working around entirely invented problems
which would be avoided by simply dropping complex control flow constructs
from web assembly.

In addition, the insistence of higher level constructs leads to some
pathological cases. For example, Duff's Device ends up with horrible web
assembly output, as seen by messing around in The Wasm Explorer.
However, the inverse is not true: Everything that can be expressed
in web assembler can be trivially converted to an equivalent in some
unstructured, goto based format.

So, at the very least, I'd like to suggest that the web assembly team add
support for arbitrary labels and gotos. If they choose to keep the higher
level constructs, it would be a bit of wasteful complexity, but at least
compiler writers like me wold be able to ignore them and generate output
directly.

Polyfilling:

One of the concerns I have heard when discussing this is that the loop
and block based structure allows for easier polyfilling of web assembly.
While this isn't entirely false, I think that a simple polyfill solution
for labels and gotos is possible. Whiie it might not be quite as optimal,
I think that it's worth a little bit of ugliness in the bytecode in order
to avoid starting a new tool with built in technical debt.

If we assume an LLVM (or QBE) like syntax for web assmembly, then some code
that looks like:

int f(int x) {
    if (x == 42)
        return 123;
    else
        return 666;
}

might compile to:

 func @f(%x : i32) {
    %1 = test %x 42
jmp %1 iftrue iffalse

 L0:
    %r =i 123
jmp LRet
 L1:
    %r =i 666
jmp LRet
 Lret:
    ret %r
 }

This could be polyfilled to Javascript that looks like:

function f(x) {
    var __label = L0;
    var __ret;

    while (__label != LRet) {
        switch (__label) {
        case L0:
            var _v1 = (x == 42)
            if (_v1) {__lablel = L1;} else {label = L2;}
            break;
        case L1:
            __ret = 123
            __label = LRet
            break;
        case L2;
            __ret = 666
            __label = LRet
            break;
        default:
            assert(false);
            break;
    }
}

Is it ugly? Yeah. Does it matter? Hopefuly, if web assembly takes off,
not for long.

And if not:

Well, if I ever got around to targeting web assembly, I guess I'd generate code
using the approach I mentioned in the polyfill, and do my best to ignore all of
the high level constructs, hoping that the compilers would be smart enough to
catch on to this pattern.

But it would be nice if we didn't need to have both sides of the code generation
work around the format specified.

the structure does help here for common code patterns

I'm not seeing any common code pattern that are easier to represent in terms of branches to arbitrary labels, vs the restricted loops and blocks subset that web assembly enforces. I could see a minor benefit if there was an attempt to make the code closely resemble the input code for certain classes of langauge, but that doesn't seem to be a goal -- and the constructs are a bit bare if they were there for

Blocks that can be ordered into a DAG can be expressed in the wasm blocks and branches, such as your example.

Yes, they can be. However, I'd strongly prefer not to add extra work to determine which ones can be represented this way, versus which ones need extra work. Realistically, I'd skip doing the extra analysis, and always just generate the switch loop form.

Again, my argument isn't that loops and blocks make things impossible; It's that everything they can do is simpler and easier for a machine to write with goto, goto_if, and arbitrary, unstructured labels.

Perhaps have a look at binaryen which might do much of the work for your compiler backend.

I already have a serviceable backend that I'm fairly happy with, and plans to fully bootstrap the entire compiler in my own language. I'd rather not add in a rather large extra dependency simply to work around the enforced use of loops/blocks. If I simply use switch loops, emitting the code is pretty trivial. If I try to actually use the features present in web assembly effectively, instead of doing my damndest to pretend they don't exist, it becomes a good deal more unpleasant.

There have been other requests for more general CFG support, and some other approaches using loops mentioned, but perhaps the force is elsewhere at present.

I'm still not convinced that loops have any benefits -- anything that can be represented with a loop can be represented with a goto and label, and there are fast and well known conversions to SSA from flat instruction lists.

As afar as CPS goes, I don't think that there needs to be explicit support -- it's popular in FP circles because it's fairly easy to convert to assembly directly, and gives similar benefits to SSA in terms of reasoning (http://mlton.org/pipermail/mlton/2003-January/023054.html); Again, I'm not an expert on it, but from what I remember, the invocation continuation gets lowered to a label, a few movs, and a goto.

Would you keep the values stack, or use a register based design?

I don't actually have any strong feelings on that end. I'd imagine compactness of the encoding would be one of the biggest concerns; A register design may not fare that well there -- or it may turn out to compress fantastically over gzip. I don't actually know off the top of my head.

Performance is another concern, although I suspect that it might be less important given the ability to cache binary output, plus the fact that download time may outweigh the decoding by orders of magnitude.

Would be interesting to know how they compare with wasm SSA decoders, that is the important question?

If you're decoding to SSA, that implies that you'd also be doing a reasonable amount of optimization. I'd be curious to benchmark how significant decoding performance is in the first place. But, yes, that's definitely a good question.

Thanks for your questions and concerns.

It's worth noting that many of the designers and implementors of
WebAssembly have backgrounds in high performance, industrial JITs, not only
for JavaScript (V8, SpiderMonkey, Chakra, and JavaScriptCore), but also in
LLVM and other compilers. I personally have implemented two JITs for Java
bytecode and I can attest that a stack machine with unrestricted gotos
introduces quite some complexity in decoding, verifying, and constructing a
compiler IR. In fact, there are many patterns that can be expressed in Java
bytecode that will cause high-performance JITs, including both C1 and C2 in
HotSpot to simply give up and relegate the code to only running in the
interpreter. In contrast, constructing a compiler IR from something like an
AST from JavaScript or another language is something I've also done. The
extra structure of an AST makes some of this work far simpler.

The design of WebAssembly's control flow constructs simplifies consumers by
enabling fast, simple verification, easy, one pass conversion to SSA form
(even a graph IR), effective single-pass JITs, and (with postorder and the
stack machine) relatively simple in-place interpretation. Structured
control makes irreducible control flow graphs impossible, which eliminates
a whole class of nasty corner cases for decoders and compilers. It also
nicely sets the stage for exception handling in WASM bytecode, for which V8
is already developing a prototype in concert with the production
implementation.

We've had a lot of internal discussion between members about this very
topic, since, for a bytecode, it's one thing that is most different from
other machine-level targets. However, it's not any different than targeting
a source language like JavaScript (which many compilers do these days) and
requires only minor reorganization of blocks to achieve structure. There
are known algorithms to do this, and tools. We'd like to provide some
better guidance for those producers with start with an arbitrary CFG to
communicate this better. For languages targeting WASM directly from an AST
(which is actually something V8 does now for asm.js code--directly
translating a JavaScript AST to WASM bytecode), there is no restructuring
step necessary. We expect this to be the case for many language tools
across the spectrum that don't have sophisticated IRs inside.

On Thu, Sep 8, 2016 at 9:53 AM, Ori Bernstein [email protected]
wrote:

Would you keep the values stack, or use a register based design?

I don't actually have any strong feelings on that end. I'd imagine
compactness of the encoding would be one of the biggest concerns; As you
mentioned, performance is another.

Would be interesting to know how they compare with wasm SSA decoders, that
is the important question?

If you're decoding to SSA, that implies that you'd also be doing a
reasonable amount of optimization. I'd be curious to benchmark how
significant decoding performance is in the first place. But, yes, that's
definitely a good question.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#796 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALnq1Iz1nn4--NL32R9ev0JPKfEnDyvqks5qn77cgaJpZM4J3ofA
.

@titzer

Thanks @titzer, I was developing a suspicion that Wasm's structure had a purpose beyond just similarity to asm.js. I wonder though: Java bytecode (and CIL) don't model CFGs or the value stack directly, they have to be inferred by the JIT. But in Wasm (especially if block signatures are added) the JIT can easily figure out what's going on with the value stack and control flow, so I wonder, if CFGs (or irreducible control flow specifically) were modeled explicitly like loops and blocks are, might that avoid most of the nasty corner cases you're thinking of?

There's this neat optimization that interpreters use that relies on irreducible control flow to improve branch prediction...

@oridb

@oridb

I'd like to argue that a flatter, goto based format would be far more useful as
a target for compiler developers

I agree that gotos are very useful for many compilers. That's why tools like Binaryen let you generate arbitrary CFGs with gotos, and they can convert that very quickly and efficiently into WebAssembly for you.

It might help to think of WebAssembly as a thing optimized for browsers to consume (as @titzer pointed out). Most compilers should probably not generate WebAssembly directly, but rather use a tool like Binaryen, so that they can emit gotos, get a bunch of optimizations for free, and don't need to think about low-level binary format details of WebAssembly (instead you emit an IR using a simple API).

Regarding polyfilling with the while-switch pattern you mention: in emscripten we started out that way before we developed the "relooper" method of recreating loops. The while-switch pattern is around 4x slower on average (but in some cases significantly less or more, e.g. small loops are more sensitive). I agree with you that in theory jump-threading optimizations could speed that up, but performance will be less predictable as some VMs will do it better than others. It is also significantly larger in terms of code size.

@titzer

It might help to think of WebAssembly as a thing optimized for browsers to consume (as @titzer pointed out). Most compilers should probably not generate WebAssembly directly, but rather use a tool like Binaryen...

I'm still not convinced that this aspect is going to matter that much - again, I suspect the cost of fetching the bytecode would dominate the delay the user sees, with the second biggest cost being the optimizations done, and not the parsing and validation. I'm also assuming/hoping that the bytecode would be tossed out, and the compiled output is what would be cached, making the compilation effectively a one-time cost.

But if you were optimizing for web browser consumption, why not simply define web assembly as SSA, which seems to me both more in line with what I'd expect, and less effort to 'convert' to SSA?

You can start to parse and compile while downloading, and some VMs might not do a full compile up front (they might just use a simple baseline for example). So download and compile times can be smaller than expected, and as a result parsing and validation can end up a significant factor in the total delay the user sees.

Regarding SSA representations, they tend to have large code sizes. SSA is great for optimizing code, but not for serializing code compactly.

@kripken

Well, it's probably too late now, but I'd like to question the idea that the relooper algorithm, or variants thereof, can produce "good enough" results in all cases. They clearly can in most cases, since most source code doesn't contain irreducible control flow to start with, optimizations don't usually make things too hairy, and if they do, e.g. as part of merging duplicate blocks, they can probably be taught not to. But what about pathological cases? For example, what if you have a coroutine which a compiler has transformed to a regular function with structure like this pseudo-C:

void transformed_coroutine(struct autogenerated_context_struct *ctx) {
	int arg1, arg2; // function args
	int var1, var2, var3, …; // all vars used by the function
	switch (ctx->current_label) { // restore state
	case 0:
		// initial state, load function args caller supplied and proceed to start
		arg1 = ctx->arg1;
		arg2 = ctx->arg2;
		break;
	case 1: 
		// restore all vars which are live at label 1, then jump there
		var2 = ctx->var2; 
		var3 = ctx->var3;
		goto resume_1;
	[more cases…]
	}
	
	[main body goes here...]
	[somewhere deep in nested control flow:]
		// originally a yield/await/etc.
		ctx->var2 = var2;
		ctx->var3 = var3;
		ctx->current_label = 1;
		return;
		resume_1:
		// continue on
}

So you have mostly normal control flow, but with some gotos pointed at the middle of it. This is roughly how LLVM coroutines work.

I don't think there's any nice way to reloop something like that, if the 'normal' control flow is complex enough. (Could be wrong.) Either you duplicate massive parts of the function, potentially needing a separate copy for every yield point, or you turn the whole thing into a giant switch, which according to @kripken is 4x slower than relooper on typical code (which itself is probably somewhat slower than not needing relooper at all).

The VM could reduce the overhead of a giant switch with jump threading optimizations, but surely it's more expensive for the VM to perform those optimizations, essentially guessing how the code reduces to gotos, than to just accept explicit gotos. As @kripken says, it's also less predictable.

Maybe doing that kind of transformation is a bad idea to start with, since afterward nothing dominates anything so SSA-based optimizations can't do much… maybe it's better done at the assembly level, maybe wasm should eventually get native coroutine support instead? But the compiler can perform most optimizations before doing the transformation, and it seems that at least the designers of LLVM coroutines didn't see an urgent need to delay the transformation until code generation. On the other hand, since there's a fair amount of variety in the exact semantics people want from coroutines (e.g. duplication of suspended coroutines, ability to inspect 'stack frames' for GC), when it comes to designing a portable bytecode (rather than a compiler), it's more flexible to properly support already-transformed code than to have the VM do the transformation.

Anyway, coroutines are just one example. Another example I can think of is implementing a VM-within-a-VM. While a more common feature of JITs is side exits, which don't require goto, there are situations that call for side entries - again, requiring goto into the middle of loops and such. Another would be optimized interpreters: not that interpreters targeting wasm can really match those targeting native code, which at minimum can improve performance with computed gotos, and can dip into assembly for more… but part of the motivation for computed gotos is to better leverage the branch predictor by giving each case its own jump instruction, so you might be able to replicate some of the effect by having a separate switch after each opcode handler, where the cases would all just be gotos. Or at least have an if or two to check for specific instructions that commonly come after the current one. There are some special cases of that pattern that might be representable with structured control flow, but not the general case. And so on…

Surely there's some way to allow arbitrary control flow without making the VM do a lot of work. Straw man idea, might be broken: you could have a scheme where jumps to child scopes are allowed, but only if the number of scopes you have to enter is less than a limit defined by the target block. The limit would default to 0 (no jumps from parent scopes), which preserves the current semantics, and a block's limit can't be greater than the parent block's limit + 1 (easy to check). And the VM would change its dominance heuristic from "X dominates Y if it is a parent of Y" to "X dominates Y if it is a parent of Y with distance greater than Y's child jump limit". (This is a conservative approximation, not guaranteed to represent the exact dominator set, but the same is true for the existing heuristic - it's possible for an inner block to dominate the bottom half of an outer one.) Since only code with irreducible control flow would need to specify a limit, it wouldn't increase code size in the common case.

Edit: Interestingly, that would basically make the block structure into a representation of the dominance tree. I guess it would be much simpler to express that directly: a tree of basic blocks, where a block is allowed to jump to a sibling, ancestor, or immediate child block, but not to a further descendant. I'm not sure how that best maps onto the existing scope structure, where a "block" can consist of multiple basic blocks with sub-loops in between.

@neelance

More specifically, they didn't find it to be a significant factor for C/C++. That might have more to do with C/C++ than with the performance of irreducible control flow. (I honestly don't know.) It sounds like @neelance has reason to believe the same would not be true for Go.

My sense is that there are multiple facets to this problem, and its worthwhile tackling it through multiple directions.

First, it sounds like there's a general issue with the generatability of WebAssembly. Much of that is caused by WebAssembly's constraint to have a compact binary with efficient type-checking and streaming compilation. We could address this issue at least partly by developing a standardized "pre"-WebAssembly that is easier to generate but which is guaranteed to be translatable to "true" WebAssembly, ideally through just code duplication and insertion of "erasable" instructions/annotations, with at least some tool providing such translation.

Second, we can consider what features of "pre"-WebAssembly are worth directly incorporating into "true" WebAssembly. We can do this in an informed manner because we will have "pre"-WebAssembly modules that we can analyze before they have been contorted into "true" WebAssembly modules.

Some years ago I tried compiling a particular bytecode emulator for a dynamic language (https://github.com/ciao-lang/ciao) to webassembly and the performance was far from optimal (sometimes 10 times slower than the native version). The main execution loop contained a large bytecode dispatch switch, and the engine was finely tuned for decades to run on actual hardware, and we make heavy use of labels and gotos. I wonder if this kind of software would benefit from support for irreducible control flow or if the problem was another one. I didn't have time to do further investigation but I'd happy to try again if things are known to have improved. Of course I understand that compiling other languages VM to wasm is not the main use case, but I'd be good to know if this will be eventually feasible, specially since universal binaries that run efficiently, everywhere, is one of the promised advantages of wasm. (Thanks and apologies if this particular topic has been discussed in some other issue)

@jfmc

@jfmc My understanding is that, if the program is realistic (i.e. not contrived in order to be pathological) and you care about its performance, then it is a perfectly valid use case. WebAssembly aims to be a good general-purpose target. So I think it would be great to gain an understanding of why you saw such significant slowdown. If that happens to be due to restrictions on control flow, then that would be very useful to know in this discussion. If it happens to be due to something else, then that would still be useful to know for how to improve WebAssembly in general.

TinyCC with WebAssembly backend would be awesome... a fast in-browser C compiler

https://lists.gnu.org/archive/html/tinycc-devel/2020-02/msg00017.html

Another motivating reminder of what could be, if & hopefully when.

@hoodmane

Python port to WebAssembly would benefit greatly from computed gotos. When we added computed goto support to CPython's ceval loop (core bytecode VM loop) many years ago, we saw an overall performance improvement of approx. 15 to 20% on platforms that use GCC and clang. I assume that addition of computed goto support in the WASM compiler tool chain would result in similar speedups.

Eli Bendersky's old blog post explains how Python's ceval loop benefits from more efficient machine code from computed gotos.

@hoodmane @rth @mdboom

I read the blog post, and it seems to be a result of their version of C not having an "unreachable" statement.

However, in wasm you won't see those improvements since even a computed goto has to have validity checks unless the engine can infer them statically.

@taralx

@taralx I think the more important part is the branch prediction:

for each jump, the branch predictor keeps a prediction of where it will jump next. If there's a jump per opcode, this is equivalent to predicting the second opcode in an opcode pair, which actually has some chance of success from time to time. On the other hand, if there's just a single jump, the prediction is shared between all opcodes and they keep stepping on each other's toes with each iteration.

I can't say for sure which one of the two factors weighs more in the speed difference between the switch and the computed goto, but if I had to guess I'd say it's the branch prediction.

Also:

in wasm you won't see those improvements since even a computed goto has to have validity checks unless the engine can infer them statically.

This is the point of the funclet proposal, which would be perfect for our use case. The entire table is statically determined so all of the validity checks are static.

If making a language (like an esolang based on early BASICs), goto is definitely almost a necessity for the backend. It's currently looking like the project i'm working on will need to sacrifice some accuracy to avoid deeply nesting everything in blocks. This format also seems to work better for multi-backend compilers that might already compile everything into a load of jump instructions emitted as assembly, GNU Lightning IR, or some other unstructured format.

I think I may have a solution, although it does involve changing the way WebAssembly works.

Instead of compiling to IR that might be JIT'd, executed, or what have you, change the WASM standard to be a proper assembly, ie with jumps and all that. This makes it hard to recompile to a faster assembly, but some people wouldn't need to recompile if it already had jumps.

For those that want to use it as an IR, there should be a way to make a pointer manifest to be included with the assembly somehow- to aid in recompiling to client code. This pointer manifest would do the same job as blocks would in defining spans.

Amendment A

Reading through, I have seen comments that this is not possible given the fact that control flow is stable. This is a niche that many would like to be filled, however.

To clarify, since I think there is a persistent misunderstanding here: arbitrary jumps would not make recompiling to faster assembly more difficult, since it is reasonably simple to detect irreducible control flow and compiling reducible control flow constructs expressed with simple jumps is arguably easier than with higher-level, nested control flow. That's why every compiler apart from V8 converts the source language's high-level control flow to jumps before optimisation (and well before translating to assembly). Irreducible control flow could make some regalloc constraint solving a bit more of a hassle but worst-case it would only make irreducible control flow a little bit slower than reducible, instead of the current situation where irreducible control flow is entirely inexpressible and therefore it must be emulated by compilers targeting Wasm. Let me reiterate: arbitrary jumps which happen to express reducible control flow are just as easy to compile as high-level control flow constructs. V8 is the only compiler to my knowledge which would find it particularly difficult to compile irreducible control flow, and the relooper algorithm which LLVM uses when generating Wasm could just be integrated into V8 itself if gotos were implemented into the Wasm standard.

Not to mention that it's years-old knowledge that V8 can't handle irreducible control flow - they might have updated the internals in the past 3+ years, in which case there is no compiler to my knowledge that would find it harder to handle gotos than nested control flow.

the relooper algorithm which LLVM uses when generating Wasm could just be integrated into V8 itself if gotos were implemented into the Wasm standard

In theory yes, but as mentioned 6 years ago in this discussion, that would move a significant amount of work from the toolchain side to the client. In general wasm tries to do the opposite (in order to achieve fast startup, and to reduce the risk of client-side bugs).

Meanwhile, in the years since the earlier discussions here, wasm has added more dependencies on structured control flow, like non-nullable locals (quick overview) and exceptions. All those things would either not be compatible with arbitrary gotos or require work to figure out how to support them there. Overall it's not impossible to support irreducibility but it is getting harder over time I think.

I used to think this issue was necessary. Then I had the idea of an inverse relooper algorithm. Every compiler would run relooper, and V8 can run that output directly and call it a day. Runtimes that support irreducible CFGs can detect that relooper was used from that giant loop and switch, and they can invert the algorithm to get back the original CFG

@danielzgtg

@danielzgtg This is what I was suggesting in the comment linked above. The algorithm to undo the loop over the switch is a relatively straightforward generalization of tail duplication, a well-known compiler optimization that can be done by the engine after it's created a CFG. If that CFG is in SSA form, it will look like this:

loop block S // predecessors A, B, ....
  x = phi(0, 1, ...)
  switch (x)
    0 => block B
    1 => block A
    ...

block A
 ...
 goto S // corresponds to setting x = 0

block B
 ...
 goto S // corresponds to setting x = 1

Block S switches on a phi defined in S. Blocks A and B goto S and their corresponding phi input is a constant. Which means that if S were tail-duplicated into both A and B separately, each copy would fold x to either 0 or 1, respectively. Which leads to constant folding of the switch, which yields a goto.

Then we end up with:

block A
  ...
  goto B

block B
  ...
  goto A

Which is your classic irreducible loop.

All this is to say, it's always been within engines' power to do this optimization and reintroduce irreducible loops, if they are prepared to handle them throughout the rest of their backends.

For the record, AFAICT, all the web engines that I am aware of have exactly the same limitations as TurboFan in their optimizing tiers. None support irreducible control flow--but could, given the above.

I used to think this issue was necessary. Then I had the idea of an inverse relooper algorithm. Every compiler would run relooper, and V8 can run that output directly and call it a day.

Aren't there considerably more compilers out there than webassembly runtimes? That makes me wonder if putting it on the compiler side is a great idea, instead of just implementing the handling of this in V8 instead. Since otherwise, every compiler out there targeting webassembly will need to reimplement this convoluted workaround. That doesn't seem like a great solution.

Navigation Menu

Repository navigation

Please Support Arbitrary Labels and Gotos. #796

My Complaints:

Polyfilling:

And if not:

146 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Please Support Arbitrary Labels and Gotos. #796

Description

My Complaints:

Polyfilling:

And if not:

Activity

oridb commented on Sep 8, 2016

oridb commented on Sep 8, 2016

titzer commented on Sep 8, 2016

qwertie commented on Sep 8, 2016

kripken commented on Sep 8, 2016

oridb commented on Sep 8, 2016

kripken commented on Sep 8, 2016

comex commented on Dec 7, 2016

146 remaining items

RossTate commented on Apr 8, 2021

jfmc commented on Apr 9, 2021

RossTate commented on Apr 9, 2021

d4tocchini commented on Dec 4, 2021

tiran commented on May 16, 2022

taralx commented on May 16, 2022

hoodmane commented on May 16, 2022

enderger commented on Jan 18, 2023

eira-fransham commented on Apr 2, 2023

kripken commented on Apr 2, 2023

danielzgtg commented on Apr 2, 2023

titzer commented on Apr 3, 2023

ell1e commented on Feb 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions