felix314159 wrote: > Hi there, Before I'd look at the patch, let me ask a couple of clarifying > questions. > > 1. Why did you work on this issue? I'd like to understand the motivation > first. > > 2. Have you used some AI and to what degree? > > 3. Have you explored the llvm algorithms and datastructures that could > help you with an implementation?
Hi, it is my first contribution to LLVM so I am sorry if I messed up sth process-related. 1. I grep'd for TODOs in production code and found this. I then felt challenged in regards to `CallDescriptionMap` because the existing comment specifically proposed a potential performance improvement and I wanted to know whether that would be significant or not. 2. Yes, Codex assisted me during the initial investigation when constructing the benchmark. I reviewed the resulting changes and test results, and I now have updated the PR description with this disclosure. 3. I considered LLVM's data structures and selected `llvm::StringMap` because the index is keyed by function name, with `llvm::SmallVector` storing the uncommon case of multiple descriptions sharing a name. But I retained the original vector because some descriptions require fuzzy or special matching. I didn't look into every potentially applicable LLVM algorithm or container, so I would appreciate suggestions if anyone has a better idea. https://github.com/llvm/llvm-project/pull/219441 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
