問題タブ [hoopl]

私はHooplライブラリを使用しており、書き換え中に何らかの状態を保持したいと考えています。State書き換え関数は、使用されるモナドに関してポリモーフィックですが、モナドをライブラリのモナドの 1 つと組み合わせる方法がわかりませんFuel。

以下は最小限の例です。MyMonadHooplCheckingFuelMonadとフラグを持つStateモナドを組み合わせたシノニムです。Stmt私の中間言語の単なるプレースホルダーであり、それほど重要ではありません.

しかし、これはコンパイルされません -- GHCrewriteは間違った型を持っていると文句を言います:

私がやりたいことは可能ですか？rewrite関数を正しく記述するにはどうすればよいですか?

Hooplの（順方向）書き換え関数のタイプは、次の関数で指定されmkFRewriteます。

このmタイプは、書き換え中にモナディック効果を使用できることを意味します。論文「Hoopl：データフロー分析と変換のためのモジュール式で再利用可能なライブラリ」は、セクション4.3「書き換え関数とクライアントのモナド」で同じことを述べています。

非Hooplモナディック効果が埋め込まれている書き換え関数の例を教えてもらえますか？たとえば、Stateモナドを使用したりIOを実行したりするリライター。

Hooplをコンパイラーに導入しようとしていますが、いくつかの問題に直面しました。Hooplのグラフを作成すると、導入されたラベルの順にノードが表示されます。

例えば：

に「コンパイル」

ASTからの再帰的なグラフ構築の順序のため、命令の順序（showGraphの順序）は奇妙です。コードを生成するには、より自然な方法でブロックを並べ替える必要があります。たとえば、関数の最後にRETVALを返し、次のようにブロックをマージします。

1つのブロックに、というように続きます。私は次のようなものが必要なようです：

これをHooplで実行する方法が完全に混乱しています。もちろん、すべてのノードをダンプしてから、Hooplフレームワークの外部で変換を実行することもできますが、これは悪い考えだと思います。

誰かが私に接着剤をくれませんか？有用な例は見つかりませんでした。Lambdachineプロジェクトでも同様のことが実行されていますが、複雑すぎるようです。

別の質問もあります。すべてのCall命令を非ローカルにするポイントはありますか？Callの実装がローカル変数を変更せず、常に制御をブロックの次の命令に移すことを考えると、これのポイントは何ですか？通話指示が次のように定義されている場合

そのため、グラフはさらに奇妙に見えます。だから私は使用します

私はこれが間違っているのでしょうか？

私は Haskell プログラマー (私は一般的に Haskell でアルゴリズムを実装しています) であり、 HOOPLライブラリを理解しようとしていますが、デコードできません。私はコンパイラのバックグラウンドを持っていません (現在、Coursera と Compilers: Principles, Techniques, and Tools から学んでいます)。HOOPL ライブラリを理解するための体系的な方法を提案していただければ幸いです (前提条件は何ですか)。HOOPL を使用してデータ フローの最適化を適用したい小さな Haskell コードがあるとします。

これを最適化するための HOOPL コードの書き方。もう少し良い例を挙げていただければ幸いです。私がばかげているように聞こえたらご容赦ください。

私は Hoopl ライブラリを使用するプロジェクトに取り組んでいますが、内部で何が起こっているのか完全に理解していないことを示す障害に遭遇しました。一言で言えば、Hoopl は私のグラフ内のいくつかのブロックを到達不能と見なしているようです (IMO) すべきではありません。私はまばらな条件付き定数の伝播を実装しているので、一部のブロックが到達不能になると予想していますが、すべてのブロックではありません! 以下は、プロトタイプ作成に使用している HUnit テスト スイートからの例です。この例では、ここで定義されていないいくつかの関数を使用していますが、それらが単独で動作すること、特に期待どおりに動作することなどを確認するために、個別の単体テストを用意していfromHoopl . toHoopl xます。

私が期待しているblock_cprop_outのは、このパスを実行した結果であるはずですが、実際の結果は の const 折り畳みバージョンにすぎませんblock_cprop_in_0。 true ブランチと false ブランチの両方が削除されています。HUnit テストからの出力は、コード スニペットの下にあります。

私が行っていることを大まかに要約すると、ブロックごとに閉じた/閉じた Hoopl グラフを作成し、これらのグラフを とマージしますHoopl.|*><*|。シンプルな を使用してData.Map、Hoopl がユーザー ラベルに割り当てる一意のラベルを追跡します。これにより、 を書き直すときにBranch userlabel、Hoopl の後継ラベルを正しい Hoopl に変更できますLabel。ただし、この前方分析を実行して書き直した後、エントリ ブロックのみを含むグラフが返されるため、Hoopl は true 分岐ブロックと false 分岐ブロックの両方がここでは到達不能であると見なしているようです。

block_cprop_outここでは少し奇妙です。なぜなら、私のfromHoopl関数は単純にHoopl.foldGraphNodesHoopl 全体Graph aを単純な[a]検査用に変えるために呼び出しているからです。

別のテストでは、同じグラフ構築方法 (閉じたブロックと閉じたブロックを連結する) を使用してこのブロックのリストをラウンドトリップすることが期待どおりに機能することが確認されています。到達不能ブロックの除去は、特にによってトリガーされるようHoopl.analyzeAndRewrite{Fwd,Bwd}です。

私がここでやっているように、閉じた/閉じたブロックのリストをつなぎ合わせることは正しいですか? もしそうなら、Hoopl にブロックが到達不能であると信じ込ませている可能性がある、他に何か疑わしいものを見つけることができますか?

HUnit の出力は次のとおりです。