tedwoodward wrote:
> The only real "gotcha" question I can come up with is, wouldn't a user who is > interested in custom instructions already have access to a compiler that > produces them and that compiler is likely to be llvm, so is lldb from that > llvm not within reach already? > > Educate me on that, I don't know how folks approach developing these > extensions. Maybe code generation is the last thing they do, after they know > it's worth pursuing. So you've got a lot of hand written assembler and `.inst > <encoding>` going on. This particular PR has to do with Qualcomm's push to be more open source. We don't want to provide custom toolchains for things with good upstream support. That's why we're pushing a bunch of our former downstream code upstream; Polly vectorizer changes, LLVM vectorizer changes, etc. It's made upstream clang performance much closer to downstream clang performance. We got the Xqci guys to open source their extension definition so we could upstream the TD files for it. But...not everyone wants to upstream their extensions, and some people don't want to build a custom toolchain for every little extension. So they decided to use the .insn assembler directive (supported for at least 5 years, according to a quick google search), and a filter program to pipe objdump output through. > LLDB's release notes live in a section of LLVM's - > https://github.com/llvm/llvm-project/blob/main/llvm/docs/ReleaseNotes.md#changes-to-lldb. Thank you! https://github.com/llvm/llvm-project/pull/145793 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
