Define opcodes in terms of smaller "micro-ops"

[brandtbucher]

We've talked about this concept on-and-off for some time now, so I thought I would create this issue to collect some concrete ideas and start trying to reach a consensus on what the best path to take here is. This is a big, high-risk project, so we should probably start discussing it sooner rather than later.

Currently, our instructions are pretty much defined as "whatever the corresponding blob of C code in ceval.c does". While there are several places (mark_stacks, stack_effect, dis and its docs, the various haswhatever lists in opcode.py) that describe aspects of their behavior, they are scattered all over the place and must be kept in-sync (by hand) with the actual implementation. In other words, they are a burden just as much as they are a useful resource.

It's also not always very clear (for example):

• How many stack items a given opcode expects.
• If it clobbers, duplicates, or swaps any of them.
• If it can push a NULL to the stack.
• If it can handle a NULL on the stack.
• If it checks for tracing.
• If it's a superinstruction.
• If it can pop a frame.
• If it can push a frame.
• If it uses its oparg.
• If it can raise.
• If it can check for eval breakers.
• If it jumps forwards, backwards, or neither.
• If it branches.

And potentially, in the future:

• If it uses or leaves unboxed values on the stack.
• If it uses or leaves borrowed references on the stack.

...and, of course, much more.

One way to improve this situation is by ditching the free-form C code and defining our opcodes in terms of structured, statically-analyzable micro-ops (or "uops"). These uops represent lowered, composable units of work, such as incrementing the instruction pointer, decrementing a value's reference count, writing values to the stack, etc. Ideally, they'd represent a sort of IR that bridges the gap between Python and native code.

Last week I put together a simple proof-of-concept that converts much of the common logic in our instructions to a couple dozen initial uops. There is much more to be done, of course, but it does a pretty good job of communicating what this could look like, and many opcodes have been mostly or entirely converted. Note that GitHub collapses the huge ceval.c diff by default, but most of the interesting stuff is there.

Other random thoughts to spark discussion:

• While our 3.12 workflow graph has an edge leading from "Move opcode definitions to their own file and generate PyEval_EvalDefault" to "Breakup instruction definitions into 'mini-ops'", I believe that we may benefit from inverting that dependency. Defining opcodes in terms of uops gives us much more power and flexibility when generating things like eval loops, since:
  • A sequence of uops is much easier to define and maintain declaratively than free-form C code.
  • Sequences of uops are easier (and more efficient) to automatically combine into things like superinstructions.
  • We can use them to also generate things like mark_stacks and stack_effect, or eval loops with debugging features added or removed.
• Uops will likely help if/when we start recording and compiling traces, since they are much simpler, explicit operations that are more granular than normal opcode boundaries. They also make things like guard-elimination and refcount-elimination a bit more ergonomic.
• It's not totally clear whether core devs will like using uops. They might lower the barrier to entry for people who don't know C, but uops can also be very verbose and make some common patterns a bit awkward, at least in their current form.
• We've also had issues in the past getting MSVC to inline stuff in the eval loop, so we might need to work around that somehow.
• Since uops make it is trivial to determine what stack items and temporaries are used by a given instruction, experimenting with architectural changes like a register VM becomes a lot more straightforward.
• In general, there are lots of cool things we could do with some basic tooling to analyze or modify sequences of uops. As a simple example, we could assert that specialized forms of instructions preserve some basic properties of their deoptimized forms.
• Finally, I wouldn't be surprised if something like this made life easier for alternate Python implementations. In addition to more strongly specifying the semantics of individual bytecode instructions, maintainers would only need to implement the much simpler uops and have a way of composing them. New/changed uops are much easier to update, and adding or changing opcode implementations is only a matter of using the new uop sequence.

[markshannon]

I think the micro-ops you propose are too low level and try to do several different things:

• Define the semantics of the higher-level instructions
• Implement VM features like tracing and recording the prev-instr
• Specify the mechanism for handling the stack, rather than treating it as an abstract stack.

It also requires local variables, which moves it into the space of a IR similar to LLVM's.

From your proof of concept, LOAD_FAST is defined as:

            PyObject *value;
            UOP_JUMP(1);
            UOP_WRITE_PREV_INSTR();
            UOP_UPDATE_STATS();
            UOP_GET_FAST(value, oparg);
            if (value == NULL) {
                goto unbound_local_error;
            }
            Py_INCREF(value);
            PUSH(value);
            DISPATCH();
            UOP_STACK_ADJUST(1);
            UOP_STACK_SET(1, value);
            UOP_INCREF(value);
            UOP_NEXT_OPCODE();
            UOP_NEXT_OPARG();
            UOP_LLTRACE();
            UOP_CHECK_TRACING();
            UOP_DISPATCH();

LOAD_FAST does three things. Moves the local variable to the stack, check to see if that value is NULL, and increments its refcount:

LOAD_FAST = GET_LOCAL CHECK_UNBOUND_LOCAL INCREF_TOS ;

We need to bottom out somewhere, and the three primitives GET_LOCAL, CHECK_UNBOUND_LOCAL, INCREF_TOS seem simple enough already.

GET_LOCAL ( -- obj) {
    obj = frame->f_localsplus[oparg];
}

CHECK_UNBOUND_LOCAL(obj -- obj) {
    if (obj == NULL) {
         goto unbound_local_error;
    }
}

INCREF_TOS(obj -- obj) {
     Py_INCREF(obj);
}

The above are amenable to optimization.

Handling tracing, dispatching, etc are the responsibility of the code generator.

[markshannon]

Here's another example, LOAD_ATTR_INSTANCE_VALUE.

LOAD_ATTR_INSTANCE_VALUE needs to check the type version, whether the object has values, before extracting the value and finally checking if it is NULL.

LOAD_ATTR_INSTANCE_VALUE =
    SKIP_COUNTER TYPE_VERSION_CHECK INSTANCE_VALUES_CHECK LOAD_VALUE NULL_CHECK INCREF_TOS;

SKIP_COUNTER(#counter) {}

TYPE_VERSION_CHECK(##version obj -- obj) {
    DEOPT_IF(version != Py_TYPE(obj)->tp_version);
}

INSTANCE_VALUES_CHECK(obj -- obj) {
    assert(tp->tp_dictoffset < 0);
    assert(tp->tp_flags & Py_TPFLAGS_MANAGED_DICT);
    PyDictOrValues dorv = *_PyObject_DictOrValuesPointer(obj);
    DEOPT_IF(!_PyDictOrValues_IsValues(dorv));

LOAD_VALUE(#index obj -- attr) {
    PyDictOrValues dorv = *_PyObject_DictOrValuesPointer(obj);
    attr = _PyDictOrValues_GetValues(dorv)->values[index];
    Py_DECREF(obj);

NULL_CHECK(obj -- obj) {
    DEOPT_IF(obj == NULL);

If we are willing to have non-objects on the stack (which we can provided the code generator ensures that they never escape),
then we lower the above a bit further:

LOAD_ATTR_INSTANCE_VALUE =
    SKIP_COUNTER TYPE_VERSION_CHECK INSTANCE_VALUES_CHECK GET_VALUES_POINTER LOAD_VALUE_FROM_VALUES NULL_CHECK

GET_VALUES_POINTER(obj -- dorv: PyDictOrValues) {
    dorv = *_PyObject_DictOrValuesPointer(obj);
    Py_DECREF(obj);

LOAD_VALUE_FROM_VALUES(#index dorv: PyDictOrValues -- obj) {
    obj = _PyDictOrValues_GetValues(dorv)->values[index];

---

Note on stack effects.

(in0 -- out0 out1) is a stack effect, saying that this operation takes in0 from the stack, and puts out0 and out1 back on the stack.

#counter notes that this operation takes a 16 bit code unit from the instruction stream. ##version is a 32 bit value.

It is the job of the code generator to make sure that the stack and instruction stream are unchanged after a DEOPT_IF branch.

[brandtbucher]

I think the micro-ops you propose are too low level and try to do several different things:

• Define the semantics of the higher-level instructions

Not accomplishing this first bullet would feel like a huge missed opportunity to me in terms of tooling/testing/maintenance, but I admit that my post probably overstated the value of this relative to other, more important design goals.

• Implement VM features like tracing and recording the prev-instr
• Specify the mechanism for handling the stack, rather than treating it as an abstract stack.

It also requires local variables, which moves it into the space of a IR similar to LLVM's.

I mostly agree with your second bullet: parts of the instruction preamble and dispatch sequence can probably be omitted when actually specifying the uop sequences for generation. As you say, "handling tracing, dispatching, etc are the responsibility of the code generator". I included them in the prototype because, well, I am the code generator in this case. ;)

If you remove some of that fluff, though, our uop specifications are quite similar. As you point out, the major differences are that you want to avoid local temporaries and explicit stack manipulations in favor of using just an abstract stack that is manipulated directly by many diverse uops (similar to our current instruction set). On the surface, those both seem less desirable to me, in terms of both maintenance and usefulness.

As a simple, concrete example, here is how a couple of simple passes might optimize a recorded trace (or superinstruction) for the statement a = b + c. Click to expand:

Uop concatenation

PyObject *value, *left, *right, *sum, *tmp;
// LOAD_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(value, 0);
UOP_STACK_ADJUST(1);
UOP_STACK_SET(1, value);
UOP_INCREF(value);
// LOAD_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(value, 1);
UOP_STACK_ADJUST(1);
UOP_STACK_SET(1, value);
UOP_INCREF(value);
// BINARY_OP:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_STACK_GET(left, 2);
UOP_STACK_GET(right, 1);
UOP_BINARY_OP(sum, NB_ADD, left, right);
UOP_STACK_SET(2, sum);
UOP_DECREF(left);
UOP_DECREF(right);
UOP_STACK_ADJUST(-1);
UOP_ERROR_IF_NULL(sum);
UOP_JUMP(INLINE_CACHE_ENTRIES_BINARY_OP);
// STORE_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_STACK_GET(value, 1);
UOP_STACK_ADJUST(-1);
UOP_GET_FAST(tmp, 2);
UOP_STORE_FAST(2, value);
UOP_XDECREF(tmp);

SSA-ification

PyObject *value_0, *value_1, *left, *right, *sum, *value_2, *tmp;
// LOAD_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(value_0, 0);
UOP_STACK_ADJUST(1);
UOP_STACK_SET(1, value_0);
UOP_INCREF(value_0);
// LOAD_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(value_1, 1);
UOP_STACK_ADJUST(1);
UOP_STACK_SET(1, value_1);
UOP_INCREF(value_1);
// BINARY_OP:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_STACK_GET(left, 2);
UOP_STACK_GET(right, 1);
UOP_BINARY_OP(sum, NB_ADD, left, right);
UOP_STACK_SET(2, sum);
UOP_DECREF(left);
UOP_DECREF(right);
UOP_STACK_ADJUST(-1);
UOP_ERROR_IF_NULL(sum);
UOP_JUMP(INLINE_CACHE_ENTRIES_BINARY_OP);
// STORE_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_STACK_GET(value_2, 1);
UOP_STACK_ADJUST(-1);
UOP_GET_FAST(tmp, 2);
UOP_STORE_FAST(2, value_2);
UOP_XDECREF(tmp);

Stack-effect elimination

PyObject *value_0, *value_1, *left, *right, *sum, *value_2, *tmp;
// LOAD_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(value_0, 0);
UOP_STACK_SET(0, value_0);
UOP_INCREF(value_0);
// LOAD_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(value_1, 1);
UOP_STACK_SET(-1, value_1);
UOP_INCREF(value_1);
// BINARY_OP:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_STACK_GET(left, 0);
UOP_STACK_GET(right, -1);
UOP_BINARY_OP(sum, NB_ADD, left, right);
UOP_STACK_SET(0, sum);
UOP_DECREF(left);
UOP_DECREF(right);
UOP_ERROR_IF_NULL(sum);
UOP_JUMP(INLINE_CACHE_ENTRIES_BINARY_OP);
// STORE_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_STACK_GET(value_2, 0);
UOP_GET_FAST(tmp, 2);
UOP_STORE_FAST(2, value_2);
UOP_XDECREF(tmp);

Stack elimination

PyObject *value_0, *value_1, *sum, *tmp;
// LOAD_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(value_0, 0);
UOP_INCREF(value_0);
// LOAD_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(value_1, 1);
UOP_INCREF(value_1);
// BINARY_OP:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_BINARY_OP(sum, NB_ADD, value_0, value_1);
UOP_DECREF(value_0);
UOP_DECREF(value_1);
UOP_ERROR_IF_NULL(sum);
UOP_JUMP(INLINE_CACHE_ENTRIES_BINARY_OP);
// STORE_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(tmp, 2);
UOP_STORE_FAST(2, sum);
UOP_XDECREF(tmp);

Refcount elimination

PyObject *value_0, *value_1, *sum, *tmp;
// LOAD_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(value_0, 0);
// LOAD_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(value_1, 1);
// BINARY_OP:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_BINARY_OP(sum, NB_ADD, value_0, value_1);
UOP_ERROR_IF_NULL(sum);
UOP_JUMP(INLINE_CACHE_ENTRIES_BINARY_OP);
// STORE_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(tmp, 2);
UOP_STORE_FAST(2, sum);
UOP_XDECREF(tmp);

Frame write elimination

PyObject *value_0, *value_1, *sum, *tmp;
// LOAD_FAST:
UOP_JUMP(1);
UOP_GET_FAST(value_0, 0);
// LOAD_FAST:
UOP_JUMP(1);
UOP_GET_FAST(value_1, 1);
// BINARY_OP:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_BINARY_OP(sum, NB_ADD, value_0, value_1);
UOP_ERROR_IF_NULL(sum);
UOP_JUMP(INLINE_CACHE_ENTRIES_BINARY_OP);
// STORE_FAST:
UOP_JUMP(1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(tmp, 2);
UOP_STORE_FAST(2, sum);
UOP_XDECREF(tmp);

Jump elimination

PyObject *value_0, *value_1, *sum, *tmp;
// LOAD_FAST:
UOP_GET_FAST(value_0, 0);
// LOAD_FAST:
UOP_GET_FAST(value_1, 1);
// BINARY_OP:
UOP_JUMP(3);
UOP_WRITE_PREV_INSTR();
UOP_BINARY_OP(sum, NB_ADD, value_0, value_1);
UOP_ERROR_IF_NULL(sum);
// STORE_FAST:
UOP_JUMP(INLINE_CACHE_ENTRIES_BINARY_OP + 1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(tmp, 2);
UOP_STORE_FAST(2, sum);
UOP_XDECREF(tmp);

Temporary variable elimination

PyObject *sum, *tmp;
// LOAD_FAST:
// LOAD_FAST:
// BINARY_OP:
UOP_JUMP(3);
UOP_WRITE_PREV_INSTR();
UOP_BINARY_OP(sum, NB_ADD, localsplus[0], localsplus[1]);
UOP_ERROR_IF_NULL(sum);
// STORE_FAST:
UOP_JUMP(INLINE_CACHE_ENTRIES_BINARY_OP + 1);
UOP_WRITE_PREV_INSTR();
UOP_GET_FAST(tmp, 2);
UOP_STORE_FAST(2, sum);
UOP_XDECREF(tmp);

Or, if we know localsplus[2] (a) is already NULL:

// LOAD_FAST:
// LOAD_FAST:
// BINARY_OP:
UOP_JUMP(3);
UOP_WRITE_PREV_INSTR();
UOP_BINARY_OP(localsplus[2], NB_ADD, localsplus[0], localsplus[1]);
UOP_ERROR_IF_NULL(localsplus[2]);
// STORE_FAST:
UOP_JUMP(INLINE_CACHE_ENTRIES_BINARY_OP + 1);

The steps for analyzing and optimizing these uops are simple and intuitive to me, and hopefully others. I tried working through the same example with a uop specification closer to what you suggest, and each step seems so much more difficult. I won't straw-man by sharing my attempts, but it seems like it requires either significantly increasing the number of uops, emitting a final result that's less optimized than the one I worked out above, or adding significant complexity to the various passes to handle all of the different possible uops (rather than a tiny subset specific to that pass).

[brandtbucher]

From your proof of concept, LOAD_FAST is defined as:

Just a minor note: this looks like a typo, since it includes both old and new code. Maybe copied-and-pasted from a unified diff of the changes to LOAD_FAST_CHECK?

[gvanrossum]

Just a minor note: this looks like a typo, since it includes both old and new code. Maybe copied-and-pasted from a unified diff of the changes to LOAD_FAST_CHECK?

Yeah, Mark was definitely talking about LOAD_FAST_CHECK, which has this definition:

        TARGET(LOAD_FAST_CHECK) {
            // TODO
            PyObject *value;
            UOP_JUMP(1);
            UOP_WRITE_PREV_INSTR();
            UOP_UPDATE_STATS();
            UOP_GET_FAST(value, oparg);
            if (value == NULL) {
                goto unbound_local_error;
            }
            UOP_STACK_ADJUST(1);
            UOP_STACK_SET(1, value);
            UOP_INCREF(value);
            UOP_NEXT_OPCODE();
            UOP_NEXT_OPARG();
            UOP_LLTRACE();
            UOP_CHECK_TRACING();
            UOP_DISPATCH();
        }

I do find this distractingly verbose. It is also lacking a bit more explanation (e.g. why does every case starts with a jump? It seems that you've eliminated the next_instr++ implied by TARGET() (in the past this was part of the instruction decoding, word = *next_instr++ etc.).

I am still trying to get my head around the rest of the various proposals; I find Mark's idea, closer to a proper IR, attractive for its compactness. I think the ease of implementation of the various optimization steps is key to which way we go.

Looking at Mark's first comment again, he writes

GET_LOCAL ( -- obj) {
    obj = frame->f_localsplus[oparg];
}

What seems almost hidden here behind the near-C syntax is that this pushes obj onto the stack. Let's explore this in more depth.

[brandtbucher]

I do find this distractingly verbose. It is also lacking a bit more explanation (e.g. why does every case starts with a jump? It seems that you've eliminated the next_instr++ implied by TARGET() (in the past this was part of the instruction decoding, word = *next_instr++ etc.).

Yeah, my branch exposes these parts which are currently tucked away in the TARGET and various DISPATCH macros. They would likely be generated, not specified by us. So we can just ignore them.

The real body of the instruction is just:

PyObject *value;
UOP_GET_FAST(value, oparg);
if (value == NULL) {
    goto unbound_local_error;
}
UOP_STACK_ADJUST(1);
UOP_STACK_SET(1, value);
UOP_INCREF(value);

The if ... goto would probably be a single uop too, like Mark's CHECK_UNBOUND_LOCAL. I just haven't gotten to it yet. So more like:

PyObject *value;
UOP_GET_FAST(value, oparg);
UOP_CHECK_UNBOUND_LOCAL(value);
UOP_STACK_ADJUST(1);
UOP_STACK_SET(1, value);
UOP_INCREF(value);

[gvanrossum]

So how would the tooling for generating the eval loop work? I imagine there would be a file containing blocks like this (one block per opcode):

// opcode: LOAD_FAST_CHECK
PyObject *value;
UOP_GET_FAST(value, oparg);
UOP_CHECK_UNBOUND_LOCAL(value);
UOP_STACK_ADJUST(1);
UOP_STACK_SET(1, value);
UOP_INCREF(value);

Then the tool would read that file and generate the switch block for the eval loop in another file, which would then be #-included into ceval.c instead of the current sequence of cases, right?

So far, so good. In order to do the optimization stages you describe (very nicely) in your comment above we'd need an in-memory representation of the sequence of uops. I guess this could be somewhat similar to the blocks of instructions we currently use in the bytecode compiler. We'd have to have a way to reference variables like value, probably each variable would just be assigned a number. Then concatenating blocks of uops together would require renumbering the variables in each block consistently (I think this is what you do in your "SSA-ification" step).

And then what? Once you've reached the final optimized form you have to generate machine code (uops look terrible for an interpreter due to the dispatch overhead). So if we're going any of these routes (this applies to Mark's proposal as well) we probably should first think about our story for generating machine code.

Until then, UOPS (even the shortened form you give, augmented with more traditional TARGET() and DISPATCH() macros) look like a readability loss -- I'd much rather read the original code than the uops version, which isn't readable at all until I've memorized most of the uop definitions.

The benefit of being able to derive the stack effect and similar things just doesn't warrant the cost of the uops migration to me. So maybe we should not be so hasty to convert to uops before tackling eval loop generation.

(I have some thoughts about Mark's IR too, I'm putting those in a separate comment.)

[gvanrossum]

Regarding Mark's IR ideas, I was trying to see how it compares for Brandt's example of a = b + c but I got stuck on the proper definition of STORE_FAST.

As a refresher, LOAD_FAST_CHECK is defined like this (I'm laying it out vertically for readabillity):

LOAD_FAST_CHECK:
    GET_LOCAL
    CHECK_UNBOUND_LOCAL
    INCREF_TOS

There is no explicit PUSH uop here: GET_LOCAL pushes the local indicated by oparg on top of the stack. (OT: Why oh why did we rename LOAD_FAST to LOAD_FAST_CHECK, introducing a new LOAD_FAST that doesn't check, rather than keeping the definition of LOAD_FAST unchanged and adding LOAD_FAST_NOCHECK? That would have spared us some confusion here.)

Anyway, I was thinking about what STORE_FAST should look like in Mark's IR. He didn't give any examples that store anything so I tried this:

STORE_FAST:
    XDECREF_LOCAL
    SET_LOCAL

with IR definitions

XDECREF_LOCAL () {
    Py_XDECREF(frame->f_localsplus[oparg]);
}

SET_LOCAL (obj --) {
    frame->f_localsplus[oparg] = obj;
}

Alas, this is neither elegant, nor symmetric with the LOAD form, nor correct. (The XDECREF should happen after the store because decref operations may call out to Python code which may acces the frame and could find a pointer to freed memory.)

Second try:

STORE_FAST:
    GET_LOCAL
    SWAP
    SET_LOCAL
    XDECREF_TOS
    POP

with IR definitions:

XDECREF_TOS (obj -- obj) {
    Py_XDECREF(obj);
}

POP (obj --) {
}

SWAP (a b -- c d) {
    PyObject *tmp = b;
    c = a;
    d = tmp;
}

I don't like this definition of SWAP much. I tried to make it more elegant (note that the stack top is on the right, so b is the top of the input stack and d is the top of the output stack):

SWAP (a b -- c d) {
    c = b;
    d = a;
}

But that still requires some kind of implicit temporary, else the c = b assignment would overwrite a before it is read.

And even if we had a satisfactory SWAP, we'd still be stuck with the fact that we're loading the old variable on top of the stack just so we can decref it. This seems to require a lot of optimization effort before it's even equivalent to the current hand-written STORE_FAST definition.

So something is still missing. :-( I'm guessing this is why Brandt didn't want to post his attempts.

But we should look at MLIR and see what they are doing. Maybe we can learn from it. We should also look at the Cinder IRs (they have two, hir and lir).

[brandtbucher]

But we should look at MLIR and see what they are doing. Maybe we can learn from it.

I watched a presentation of theirs from 2020 earlier this week, and it appears on the surface that their framework is sort of overkill for what we're doing here. I guess if we wanted to, we would define our own dialect that maps to instructions/uops and define how to optimize and lower that dialect to LLVM IR. But I figure that at that point, if we want LLVM to be our backend, it may just be easier to optimize the uops ourselves and define a direct translation to LLVM IR.

Also, C++... :(

We should also look at the Cinder IRs (they have two, hir and lir).

Yeah, trycinder.com is great for exploring this. I preloaded that link with our little example, so you can see all of the passes they perform on it.

It appears that they do replace the stack with an SSA form almost immediately. Also interesting is that they include a pass to insert refcounts to IR that initially ignores them, rather than removing incref/decref pairs where possible. If we are defining our opcodes as a sequence of uops, the latter approach seems like it makes more sense, since we would just have that information anyways when we start compiling a trace. It would be interesting to learn why they went that route instead.

[gvanrossum]

it appears on the surface that their framework is sort of overkill for what we're doing here.

Yeah, we should probably not try to use MLIR directly. But we should understand it well enough to be either inspired by it to do something similar ourselves, or able to reject their approach confidently. Right now we can do neither because we don't understand their approach well enough. (At least I don't, although I've dug into their tutorial briefly.)

Yeah, trycinder.com is great for exploring this.

Oh, cool. I looked at Cinder's Hir source code a bit and it definitely looks like something we should understand better before we design our own.