[llvm] [llvm-exegesis] [AArch64] Resolving "snippet crashed while running: Segmentation fault" for Load Instructions (PR #142552)

Sjoerd Meijer via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 9 03:33:29 PDT 2025


sjoerdmeijer wrote:

This is a large change, which shows that there are a lot of moving part involved here. I understand and agree it is not easy to see what is necessary to fully support loads/stores (for AArch64). Thanks for putting up this WIP patch, maybe we can use this WIP patch to define the minimum change and use-case that we want to add first. I don't think we need to strive for complete support. So, again, I would like to see a minimal change that improves some opcodes, doesn't regress others, and very clearing stating the assumptions and things that can or should be picked up in follow ups.

Correct me if I am wrong, or if you have other opinions, but this is the first scenario I would like to see supported:
- we generate a syscall to `mmap` with ADDR is NULL, so that it returns an address to a block of memory that is has reserved.
- we use that memory address and store it in a register as the base address for the load/store operations,
- for loads/store address that have a register + register addressing mode, i.e. a base + offset calculation, I am happy if we use the mmap return address as the base, and 0 for the offset, for now, just to get something working.

If we can get some new opcodes working with this strategy, and if they give some sensible results, then I think that is forward progress. If you agree with this exercise, then let's go ahead with this, first thing you can do is to strip-out everything that is not needed to support this minimal change. I don't mind either way, if you implement this minimal change in this merge request here, or keep this one around as a reference and open a new one for the minimal change.

@davemgreen or @boomanaiden154:, if you have opinions on any of this, please let us know. 

https://github.com/llvm/llvm-project/pull/142552


More information about the llvm-commits mailing list