Files

T

Michael Schimmel 83324a1892 feat: Document AST node structure across compiler stages

Add a new Markdown document detailing the AST node structure as it
evolves through the compiler's different stages. This includes a diagram
illustrating the data flow and relationships between the generic
`Node<K, T>` structure and its specialized forms (`UntypedNode`,
`BoundNode`, `TypedNode`, `AnalyzedNode`). The document explains the
`kind` and `ty` payloads for each stage and their significance.

Also removes a deleted file related to a previous optimization plan and
adds new files for future optimization plans.

2026-02-27 08:58:38 +01:00

1.8 KiB

Raw Blame History

Record Optimization Plan

Dieses Dokument beschreibt geplante Optimierungen für Records im Myc-Compiler, um die Performance bei Datenstrukturen zu steigern.

1. Constant Folding für Record-Literale

Status: Aktuell werden Record-Literale in engine.rs nur rekursiv besucht, aber nicht gefaltet.

Ziel: Wenn alle Felder (Keys und Values) eines Records Konstanten sind, soll der gesamte Record in eine BoundKind::Constant(Value::Record(...)) transformiert werden.

Umsetzung:

In src/ast/compiler/optimizer/folder.rs eine Methode try_fold_record implementieren.
In src/ast/compiler/optimizer/engine.rs im Case BoundKind::Record diese Methode aufrufen.
Dies ermöglicht es dem bereits existierenden Folder für BoundKind::GetField, Feldzugriffe auf Literalen direkt zur Kompilierzeit aufzulösen.

2. Record Inlining in SubstitutionMap

Status: Records werden derzeit nicht aggressiv in die SubstitutionMap aufgenommen, wenn sie Variablen zugewiesen werden.

Ziel: Zuweisungen von (konstanten) Records an Variablen sollen in sub.values gespeichert werden.

Beispiel:

(def r {:x 10 :y 20})
(.x r) ; Sollte zu 10 optimiert werden

Umsetzung:

Sicherstellen, dass Value::Record von Inliner::is_inlinable_value als sicher eingestuft wird.
Testen, ob BoundKind::GetField bei einem Get auf eine Variable, die in sub.values als Record bekannt ist, den Wert extrahieren kann.

3. Propagation von Record-Layouts

Ziel: Wenn das Layout eines Records statisch bekannt ist (auch wenn die Werte nicht konstant sind), könnten Feldzugriffe (GetField) effizienter vorbereitet werden, um die Laufzeit-Suche im Layout-Hash/Index zu minimieren.

Erstellt am 26. Februar 2026 zur Nachverfolgung der Optimizer-Verbesserungen.

1.8 KiB Raw Blame History

Record Optimization Plan

1. Constant Folding für Record-Literale

2. Record Inlining in SubstitutionMap

3. Propagation von Record-Layouts

1.8 KiB

Raw Blame History