Let me rebase this to see if the tests pass.

I have rebased changes to make clear what still needs to be fixed.

The assertion hit by the tests is libevmasm/CommonSubexpressionEliminator.cpp:L386 - I'd actually say that it's not worth the effort to actually implement that part for legacy code generation - so the easiest solution to this would be to only add these simplification rules for via-IR code generation (which would require passing that down as a flag to the rule list generation).

The assertion hit by the tests is libevmasm/CommonSubexpressionEliminator.cpp:L386 - I'd actually say that it's not worth the effort to actually implement that part for legacy code generation - so the easiest solution to this would be to only add these simplification rules for via-IR code generation (which would require passing that down as a flag to the rule list generation).

Thanks for clarifying! The output wasn't really telling me much.

I could make that change. Do you have a name in mind for the flag? And do you recommend passing that flag down to each simplificationRuleListPart or just adding another "Part" that is wrapped in an if statement?

I notice that there's a few rules, evmRuleList to be specific, that are added if the _evmVersion is set (it is only set from libyul). I figure that there is the option of making use of that. The only issue is that those rules are added at the end.

Thanks for clarifying! The output wasn't really telling me much.

I could make that change. Do you have a name in mind for the flag? And do you recommend passing that flag down to each simplificationRuleListPart or just adding another "Part" that is wrapped in an if statement?

I notice that there's a few rules, evmRuleList to be specific, that are added if the _evmVersion is set (it is only set from libyul). I figure that there is the option of making use of that. The only issue is that those rules are added at the end.

Ah, right! I didn't realize myself that we don't set the evm version for legacy code generation. In that case, it makes sense to just reuse that. You can add a flag only to the rule list Part in which you add the new rules only and set it based on _evmVersion.has_value(). As for a name, maybe something like _forYulOptimizer.

I'd also add a comment before conditionally adding the new rules stating something like:

// The libevmasm optimizer does not support rules resulting in opcodes with more than two arguments.

@ekpyron Looks like that solved it! Tests are passing now 🙌

We'll still need a changelog entry for this - apart from that I think we can merge.

I've added changelog entries as well. Feel free to edit if necessary.