feat(ptodsl): support stack-local structs - #1104
Conversation
86f2368 to
9ca170b
Compare
d517e11 to
3ab1b65
Compare
3ab1b65 to
2104a12
Compare
|
|
||
| static bool hasVPTOConvertibleType(Type type) { | ||
| return isa<pto::VRegType, pto::MaskType, pto::AlignType, pto::PtrType>(type); | ||
| return isa<pto::VRegType, pto::MaskType, pto::AlignType, pto::PtrType, |
There was a problem hiding this comment.
- 签名转换处 struct 会被静默 lower 成 opaque ptr,而不是报错(最大风险)
两个 emitter 都把 pto::StructType 加进了 hasVPTOConvertibleType(VPTOLLVMEmitter.cpp:184、VPTOCANN900LLVMEmitter.cpp:408),这个谓词同时驱动 populateVPTOStructuralTypePatterns 对函数签名/调用边界的转换。PTODSL 前端虽然拒绝了 struct 作为 @pto.jit/subkernel 参数,但手写 .pto IR 或其他入口只要让 struct 出现在 func 签名上,就会被静默转成 opaque LLVM 指针参数——而调用侧永远不会创建对应的 alloca,得到的是一个语义悬空的指针,而不是一条编译错误。前端拒绝 + 后端静默放行,中间这层手写 IR 没有任何保护。建议在签名/边界转换路径上对 StructType 显式 emitError 拒绝,而不是依赖"前端已经拦了"。
|
|
||
| ```python | ||
| state_type = pto.struct_type(pto.i32, pto.f32) | ||
| nested_type = pto.struct_type(pto.i16, pto.struct_type(pto.i32, pto.f16)) |
There was a problem hiding this comment.
这个接口虽然很贴近IR形态,但感觉不太好用。我希望DSL能够直接提供一个类似class的抽象,用户可以像访问class成员一样访问struct成员,不用struct_set/struct_get。可以记个遗留后面优化吧
There was a problem hiding this comment.
成员访问形式作为后续独立的前端易用性设计处理, 新增issue#1129
| - `struct_get` 只能产生标量值,嵌套 aggregate 只能通过更长 path 访问。 | ||
| - 第一阶段只支持函数内局部 state,不建立 PTODSL 的 struct 参数 ABI。 | ||
| - `_StructDescriptor` 不可作为 runtime scalar annotation 或 loop-carried state。 | ||
| - 嵌套层级无人为上限;path resolver 必须迭代实现且不缓存跨 context 的 MLIR type。 |
There was a problem hiding this comment.
C++侧的path resolver仍然是递归实现的
There was a problem hiding this comment.
已修正文档,field-path resolver 与 VPTO storage-type construction 均采用迭代遍历
| // Struct values carry the address of stack-local storage. Keep the pointee | ||
| // type local to struct access lowering so the public type conversion remains | ||
| // an opaque LLVM pointer, consistent with other pointer-like PTO handles. | ||
| static LLVM::LLVMStructType getVPTOStructStorageType(pto::StructType structType, |
There was a problem hiding this comment.
这里是递归的,和文档设计不一致,看下要不要改
| if (failed(address)) | ||
| return rewriter.notifyMatchFailure(op, "invalid struct field path"); | ||
| rewriter.replaceOpWithNewOp<LLVM::StoreOp>(op, adaptor.getValue(), | ||
| *address); |
There was a problem hiding this comment.
这里缺了getNaturalByteAlignment(resultType),和GetOp不一致?
There was a problem hiding this comment.
pto.struct_set lowering 已显式使用 natural byte alignment,与现有 load lowering 保持一致
| @@ -0,0 +1,62 @@ | |||
| // Copyright (c) 2026 Huawei Technologies Co., Ltd. | |||
There was a problem hiding this comment.
测试缺口
- 无混合宽度/对齐布局的 lit 覆盖。GEP + 对齐最容易在 !pto.struct<i16, i32>、struct<i8, f32> 这类有 padding 的布局上出错,但 lit 测试只用了 struct<i32, struct<f32, i16>>(字段恰好都是 4 字节倍数起点)。建议加一个 struct<i16, i32> 或 struct<i8, i64> 的 case。
- 无 i8/i64/bf16 字段覆盖,公开承诺的类型列表没有被逐一验证。
- 无 ≥3 层嵌套测试,而这正是递归实现的风险点。
- EmitC 端到端缺失:test_ptoas_frontend_verify.py 里的 probe 用 backend="emitc" compile,但只断言了 frontend verify 的文本,没有断言生成的 C++。设计文档说"EmitC 由既有 lit 覆盖",但那是手写 IR 路径,PTODSL → EmitC 全链路没有一处断言。
- VPTO emitter 的 notifyMatchFailure("invalid struct field path") 分支无任何 negative 测试(正常应被 verifier 挡住,但失败诊断路径本身没验证)。
A5 板测失败
日志尾部 |
A3 板测失败
失败用例
|
A3 板测失败详情:PR #1104comm_p2p_binding_variants
comm_p2p
|
Summary
Validation