Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the LLGo compiler's SSA generation by adding a mechanism to emit semantic metadata. Specifically, it now tracks and annotates instances where concrete types are converted to interface types using Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
|
Overall: Clean, well-scoped PR. The semantic metadata emitter is a solid foundation for recording interface conversions. The golden file updates are consistent. A few items below worth addressing — mainly a redundant |
1958ac9 to
8e77b05
Compare
There was a problem hiding this comment.
Code Review
This pull request introduces an infrastructure for emitting package-level semantic metadata in the SSA backend and uses it to emit !llgo.useiface metadata for non-interface to interface conversions. The implementation includes a new semanticMetadataEmitter to manage and prevent duplicate metadata entries in the LLVM module. The changes are well-structured, with a logical refactoring in abitype.go to support the new functionality in interface.go. The code is clean, correct, and the regenerated golden files confirm the intended behavior. Overall, this is a solid improvement to the compiler's metadata emission capabilities.
57e867d to
b0f7c04
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1728 +/- ##
==========================================
+ Coverage 88.44% 88.56% +0.12%
==========================================
Files 50 52 +2
Lines 13656 13891 +235
==========================================
+ Hits 12078 12303 +225
- Misses 1369 1374 +5
- Partials 209 214 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
646581d to
1b2e89b
Compare
728feba to
a4b76a5
Compare
There was a problem hiding this comment.
will use goplus/llvm instead
There was a problem hiding this comment.
already use goplus/llvm ssa: use llvm metadata read APIs
3e35f66 to
7222776
Compare
b2b62bb to
6cad6b2
Compare
f41a4c8 to
e8fbec6
Compare
e8fbec6 to
ee34c8d
Compare
…data-producer-rework
|
这部分我不太建议新增meta-expect.txt这种类型的用例,和之前的out.ll问题一样,针对性不足,并且会受其他部分变化的影响。我建议可以新增一些有针对性的测试用例,复用同样的LITTEST机制来做检查,而不是普遍性的测试大量代码的输出。 |
明白,对于每个cl/testxxx 都输出meta-expect.txt 会导致噪音过多,这里预期会修改为针对性的用例验证metadata的产出。但如果emitter输出逻辑、abi.Type名称稳定其实这个回归也不应该变化,如果abi.Type名称变化这里更新其实是预期的~
这里复用LITTEST机制 指的是预期在cl/testxxx下面新增对应的in.go,然后标记llvm module 的 metadata的节点产出进行匹配么; 所以可能会更倾向于在cl/_testmeta下面增加 ifaceuse,interface,reflect等等的针对性用例,每个包内都是一个in.go,以及现在形状的meta-expect.txt. |
主要是需要额外维护这些东西,比如因为其他原因,改了无关用例里的类型名称,或者顺序,字段之类的,还需要再去维护metadata的输出,这就和现在的偶尔改动需要刷新大量的out.ll的情况类似
嗯嗯,我赞同这样的改法,主要是觉得把测试用例的关注点独立出来会比普遍检查输出会更好。 |
4c2a85e to
038df93
Compare
038df93 to
3b43c7f
Compare
| if obj == nil || obj.Pkg() == nil { | ||
| return true | ||
| } | ||
| return abi.PathOf(obj.Pkg()) == p.Path() |
There was a problem hiding this comment.
这里有个疑问,看起来类型只有在定义的包中有使用的时候才会判定为true,那对于import的情况,如果在定义的包中没有使用,在其他包中才有使用,是不是会缺少这个type的MethodInfo?
There was a problem hiding this comment.
#1728 (comment)
确实是一个误优化!MethodInfo 当前是随 abiUncommonMethods/abiType 按需发射的,而不是定义包统一产出,所以不应该限制为只在 owner package emit。这里将会移除这个条件,和当前 InterfaceInfo 保持一致。
| // only on definition/type-processing paths would miss rows such as | ||
| // "_llgo_foo/bar.IFmt" even though later whole-program analysis still | ||
| // needs that complete interface method set. | ||
| if _, ok := types.Unalias(intf.raw.Type).(*types.Named); ok { |
There was a problem hiding this comment.
匿名的interface是否也需要InterfaceInfo?
There was a problem hiding this comment.
已修改,匿名的interface也会需要Interface,否则后续全局视角计算下,类型是否实现接口在匿名接口的情况下会误判,已修改,并回归在 cl/_testmeta/interface_anonymous/in.go
e41d813 to
d553c34
Compare
Background
Ordinary
call/refreachability only sees direct symbol references, but in Go the question of which methods must be kept also depends on additional semantics such as:MethodByNameAn ordinary reference graph alone cannot answer:
This PR is not the end of the full pipeline. It is one implementation stage of the proposal: it emits these Go semantic facts as
llgo.xxxmetadata duringssa/cl, and adds stable readback for them.This PR corresponds to the producer / readback portion of:
llgo#1727: Proposal: Semantic Pruning of Unreachable Methods from a Global GraphThis PR only covers the producer / readback layer of the proposal. It does not include:
OrdinaryEdges/TypeChildrenWhat This PR Does
1. Emit Go semantic metadata during
ssa/clThis PR adds and wires up the following named metadata:
!llgo.useiface!llgo.useifacemethod!llgo.interfaceinfo!llgo.methodinfo!llgo.usenamedmethod!llgo.reflectmethodThey represent:
useifaceuseifacemethodinterfaceinfomethodinfoMType / IFn / TFnusenamedmethodMethodByNamereflectmethod2. Define the metadata encoding baseline
The current encoding is row-oriented to keep emission and later aggregation simple:
llgo.interfaceinfollgo.methodinfoIn particular:
methodinfois emitted only when a type actually has method slotsMethodInfokeepsIndex / MethodSig / IFn / TFn, matching the needs of later analysis3. Distinguish the emission ownership of
MethodInfoandInterfaceInfoBoth are inputs to later analysis, but they intentionally use different emission strategies in the current implementation.
MethodInfoMethodInfois tied to the method-table layout of a concrete type. Its ownership is stronger, and duplicate emission is much noisier.So this PR tightens its emission:
llgo.methodinfois no longer emitted redundantly at use sitesGeneric instances remain conservatively allowed at use sites for now:
So the current policy is:
InterfaceInfoInterfaceInforecords the complete method set of an interface. In principle it also looks like definition-site information, but under current LLGo interface lowering, named interfaces are often erased early into their underlying*types.Interface. That makes it unreliable to recover a stable named owner from the definition-side type materialization path.So the current implementation chooses:
InterfaceInfoat the use siteThis is intentional because:
InterfaceInfocontributions from multiple modules remain semantically safe after whole-program mergeIn other words, this PR intentionally treats the two differently:
MethodInfoInterfaceInfo4. Add
internal/semmetaThis PR adds
internal/semmeta, which is responsible for:llgo.xxxmetadata back from a singlellvm.ModuleModuleInfoThis layer only handles semantic metadata. It does not handle:
TypeChildren5. Use the new metadata read API from
goplus/llvmThis PR also switches to the metadata read API that has already landed in
goplus/llvm, removing the temporary cgo-based reader previously used by tests.The current code directly uses:
Module.NamedMetadataOperandsValue.MDNodeOperandsValue.MDStringto read named metadata back from
llvm.Module.6. Add
llgen.GenModuleFromThis PR adds
GenModuleFromtointernal/llgen, so callers can directly obtain anllvm.Module.That makes it possible to use the same
llvm.Modulefor both:without a stringify-then-reparse detour.
7. Build a stable semantic view for metadata
The readback result is not a raw row dump. It is a stable semantic view grouped by meaning, for example:
UseIfaceUseIfaceMethodInterfaceInfoMethodInfoUseNamedMethodReflectMethodThis captures semantic content rather than LLVM metadata node numbering or row layout details.
Current Scope
This PR only covers the producer / readback layer of the proposal. It does not include:
OrdinaryEdges/TypeChildrenIn other words, this PR establishes the input contract and observability foundation required by the later algorithm.
Representative Coverage
This PR covers several important semantic categories:
ifaceconvuseifacereader/invoke/interfaceembedunexport/geometry1370reflectmkMethod,MethodByName, and conservative reflectionabimethodcursor/reflectconv/abinamedFollow-up Work
Later PRs will continue from here with:
OrdinaryEdges,TypeChildren, and semantic metadatatype symbol -> live method indexes