Repository navigation
Transform inst(X, ...) to op(X, ...) plus macro(X) = X in code generator #109287
Description
This should make it easier for all further passes in the code generator -- they can just look at macros, ignoring the singleton instructions. @markshannon tried this in #108997 but got stuck, I hope I can get it unstuck.
It's possible that the synthetic uop will be named __X instead of _X, since the latter would create some name conflicts. (I don't think that this causes issues with __X being treated as "private" in Python, since we won't have Python-level variables named after uops.) (UPDATE: The synthetic uop and macro will both be called X.)
Activity
gvanrossum commentedon Sep 11, 2023
This is even subtler than I thought.
It might be better to reuse the Tier 1 opcodes for the Tier 2 opcodes; I haven't figured out how yet.
__X, which makes things ugly.macro(LOAD_FAST_LOAD_FAST) = LOAD_FAST + LOAD_FAST(because these need special-casing foroparg).And the savings in code are not that spectacular.
gvanrossum commentedon Sep 12, 2023
I am considering a different approach, where inst(X) translates to op(X) and macro(X) = X, so the macro name is the same as the op name. The Tier 1 pass generator can just walk over
self.macro_instrs. The Tier 2 pass generator can just walk overself.instrs. The metadata pass will need to consider both (and others,self.familiesandself.pseudos).PRIORITY: There's still an open issue for super-instructions (I think we will have to add something to the syntax).
gvanrossum commentedon Sep 13, 2023
@markshannon @brandtbucher This would be easier if we dropped the whole concept of super-instructions. There are only three left (
LOAD_FAST_LOAD_FAST,STORE_FAST_LOAD_FAST,STORE_FAST_STORE_FAST). But when these were introduced, they gave a whopping 1.7% speedup (gh-105230).gvanrossum commentedon Sep 13, 2023
Well, I managed to add the super-instruction special casing back. [UPDATE:] I also managed to reuse the opcode names and numbers for both the op and the macro, reducing the strain on the opcode namespace.
[-]Transform inst(X, ...) to op(_X, ...) plus macro(X) = _X in code generator[/-][+]Transform inst(X, ...) to op(X, ...) plus macro(X) = X in code generator[/+]gh-109287: Desugar inst(X) to op(X); macro(X) = X (#109294)
gvanrossum commentedon Sep 15, 2023
@carljm I just discovered I introduced a bug on the handling of overrides -- an overridden
inst()will be emitted twice (because there are two macro instances ineverything). I'm about to head off on vacation but maybe you or @jbower-fb can come up with a fix? FWIW I am getting tired of theeverythinglist, and would rather have various code bits iterate overself.instrs,self.macros, etc. Maybe we can tolerate not having the placeholder comment in the generated output? That would simplify a few things.gvanrossum commentedon Sep 15, 2023
(One idea before I really go: the Macro could have a copy of the override flag, and this could be used to just add
// overrideto the emitted cases. Or the code could just look in the first component for an override flag.)gvanrossum commentedon Oct 2, 2023
@carljm @jbower-fb Did you manage to confirm and fix the bug with overrides I referred to above?
carljm commentedon Oct 4, 2023
@gvanrossum No, sorry; I've had it noted on my list of things to look into, but haven't gotten to it yet. I should be able to work on it this week.
pythongh-109287: fix overrides in cases generator
gh-109287: fix overrides in cases generator (#110419)
jbower-fb commentedon Nov 3, 2023
(Sorry I didn't comment on this before, I still care about this feature but was taking some extended leave from work/Python to look after my new-born son.)
pythongh-109287: fix overrides in cases generator (python#110419)