https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #6 from Julian Seward <jsew...@acm.org> --- (In reply to Andrew Pinski from comment #5) > One idea I have is to pattern match on the ldxr/stxr sequence and produce a > single instruction in the IR and then decode them after the fact. On consideration, I think this is the least-worst option, but I would propose to do it probably differently to how you envisage. I would leave the front end alone (guest_arm64_toIR.c) and instead do pattern matching on the IR after initial optimisation and before instrumentation. That keeps the IR target independent, and it has the benefit of solving the problem for all targets, not just ARM64. The result of the pattern matching would be a encoded into a new IRStmt kind which encapsulates a complete LL-SC pair. This does have the restriction that the LL and SC would have to be within the same (extended) basic block, since otherwise they won't be in the same IRSB, but I don't think that's much of a restriction. We would then have to mess with all tools and pipeline compilation stages to handle this new construction, but there's no way around that; and we'd need to take care, in register allocation, that there will be no spilling in between the emitted LL and SC, since that would potentially scupper the entire enterprise. -- You are receiving this mail because: You are watching all bug changes.
