On 09/10/2015 11:55 AM, Alex Bennée wrote: > I've only had a quick glance so far but I'm fairly familiar with the > concept from a previous life. I'll aim to do a full review later once > I've gotten through my MTTCG review backlog. > > Anyway some quick points: > > * You can save data by only marking faulting instructions > > Assuming that all asynchronous instructions trigger at the end/prologue > of basic blocks you only actually need to record the address of > potentially faulting instructions. In fact only a few backend > instructions will actually synchronously fault. > > Of course this does have the downside of having to mark all those > instructions in the front end.
We have that. The only tcg opcodes that can fault are qemu_ld, qemu_st, and call. So, yes, I could do exactly this. Perhaps not for round 1, however? > * This method can also be used for additional rectification data > > AIUI we currently ensure all load/stores are barriers and ensure the CPU > register file is updated before the occur. However if you wanted to you > could drop that requirement and mark the target-host register pair and > only fish it out when required on a fault. Maybe. I'd have to think about this. We'd probably want to study how many flushes to the register file this could elide. My off-the-cuff guess is not enough to make the extra overhead useful. > * Test suites are essential if your going to get clever > > Last time I went through this I built a SPARC test suite to cover all > faulting instructions in all the various addressing modes. It flushed > out a lot of bugs. Indeed. It would indeed be good to add a bunch of bare-metal tests. Pre-compiled and checked in so that one doesn't have to have a suite of cross-compilers in order to use them. OTOH, I don't see myself (or anyone else) really having the time to do that. r~
