lc_ast

Documents AST usage marking and CallOp propagation rules in LuisaCompute.

1.0k|108|Updated Nov 20, 2020
One-click install
npx skills add https://github.com/LuisaGroup/LuisaCompute --skill lc-ast
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: lc_ast
Source: https://github.com/LuisaGroup/LuisaCompute/tree/main/.agents/skills/lc_ast
Command: npx skills add https://github.com/LuisaGroup/LuisaCompute --skill lc-ast

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Developers modifying LuisaCompute's AST layer need to understand how variable read/write usage is tracked and propagated through expressions, FunctionBuilder, and builtin CallOp calls, which is scattered across many headers and source files.

Core Features & Use Cases

  • Usage Marker Reference: Explains the two-layer design of per-expression usage caches and FunctionBuilder's per-variable usage storage, including RefExpr forwarding rules.
  • CallOp Marking Rules: Documents which builtin CallOps mark argument 0 as WRITE versus the default all-READ behavior, plus external and custom callable propagation.
  • Extension Guides: Provides step-by-step checklists for adding new CallOps, expressions, and statements, including which backend codegen files must be updated (CUDA, Metal, HLSL, SPIR-V, LLVM CPU, XIR).
  • Use Case: When adding a new write-style builtin operation, consult the skill to update the CallOp enum, CallExpr::_mark() switch, validation in op.cpp, and each backend's codegen switch.

Quick Start

Ask the assistant to explain how usage marking works for a specific CallOp or to walk through adding a new builtin operation to the LuisaCompute AST.

Frequently Asked Questions about lc_ast

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new CallOp in LuisaCompute?

Add the enum value in include/luisa/ast/op.h without reordering existing values, update usage marking in CallExpr::_mark() in src/ast/expression.cpp, optionally add validation in check_builtin_call_valid(), then add codegen cases in each backend such as cuda_codegen_ast.cpp and the HLSL function_codegen.cpp.

How does LuisaCompute track variable read and write usage in the AST?

Usage is tracked in two layers: each Expression caches a Usage bitfield and forwards new bits via _mark(), while RefExpr::_mark() writes through to FunctionBuilder::_variable_usages indexed by variable uid. Query results with Function::variable_usage(uid) after building.

Which builtin CallOps mark their first argument as WRITE?

Write-style builtins include BUFFER_WRITE, TEXTURE_WRITE, BINDLESS_BUFFER_WRITE, atomic operations like ATOMIC_FETCH_ADD, ray tracing instance setters, ray query ops, gradient accumulation, indirect dispatch setters, and cooperative vector stores. All other builtins mark every argument READ by default.

Which backend files need updating when adding an AST expression?

Direct-AST backends each have a switch on Expression::Tag: cuda_codegen_ast.cpp for CUDA, metal_codegen_ast.cpp for Metal, hlsl_codegen.cpp for DX12, llvm_state_visitor.cpp for Vulkan SPIR-V, codegen_visitor.cpp for CPU, plus ast2xir.cpp for XIR-based backends like HIP and Fallback.

Why is my custom callable argument not getting correct usage propagation?

For custom callables, reference and resource arguments propagate the callee's recorded variable usage, while value arguments are marked READ. Explicitly mark reference variables READ_WRITE via mark_variable_usage() so callers propagate usage correctly.