python / python/cpython

Encode immediate def-use in the JIT specializer

オープン
#148,080 コメント 4 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

interpreter-core topic-JIT type-feature
主要言語
Python
スター
77.2k
フォーク
35.9k
PR マージ指標
PR 指標を取得中

説明

Feature or enhancement

Proposal:

Our JIT IR naturally encodes liveness in it by virtue of being a stack IR. However, we're missing a crucial piece of info to allow for stronger optimizations: def-use.

Background: Normal SSA (static single assignment form) IR already naturally encodes def-use, and LLVM's SSA flavor also includes use-def as a property.

The idea of def-use is as the name suggests, to include information of where something is defined and where it is used (hence the name def-use).

We need def-use for the following optimizations:

  1. Eliminating redundant ops after we've constant folded combined with refcount elimination. The problem is that the current refcount elimination complicates the stack effect. So naturally the current remove_unneeded_uops pass cannot do its job properly for all of those, as the ref shuffling form of uops blocks it. This issue is becoming a bigger one as we are starting to constant fold more in the JIT as we record more info, which leaves a bunch of redundant ops lying around that we could really do away with. E.g we can constant fold most LOAD_ATTR, but we leave their operand loads lying around even when no guards need it.
  2. To feed info to the future partial evaluator (PE). In my past experiments, partial evaluation is not worth it if the unboxed operand goes straight into a boxed consumer (e.g. a C API call). This mostly wrecks the perf of PE. We need a good heuristic to determine if something is worth to unbox or whether we should keep it boxed. A reminder that the PE pass is planned to take info from the current specializer pass.

Design (def-use):

typedef union {
    uintptr_t bits;
} JitOptRef;

becomes

typedef struct {
    uintptr_t bits;
    _PyUOpInstruction *originator;
} JitOptRef;

At selected uops, we then assign orginator to be the originating instruction this symbol comes from. E.g.

[0xfefefefe] LOAD_FAST x

symbol x's originator will point to 0xfefefefe (LOAD_FAST).

Not that this encodes only the most recent def-use as a property of the reference, which should be safe. We do not need full def-use chains further back, as an interesting property of a stack IR I've observed, but not yet proven, is that local rewrites can generalize to a whole-trace optimization if done correctly. E.g. see how remove_unneeded_uops just by performing local rewrites is able to remove dead code for a larger-than-local chunk of the trace.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず、JIT specializer の JitOptRef の設計と、issue で言及されている remove_unneeded_uops pass を読みます。選択された uops がどこで参照を作成または更新するかを追跡し、そのうえで originator データが冗長な演算の除去と将来の部分評価の入力をどのようにサポートできるかを判断します。完了時には、既存のスタック効果の処理を壊すことなく、指定された uops に def-use 情報が含まれている必要があります。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
c, python
領域
compilers, performance
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。