Richard Henderson <r...@twiddle.net> writes: > 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?
I unfortunately haven't got a SPARC manual handy (or my old testsuite) but I was sure there was more than just loads/stores. I guess all the FP related exceptions are handled in Softfloat for QEMU and the hardcoded cases caught during instruction decode. >> * 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. Sure - more instrumentation and data would be useful for this. It's an area I'd like to look at once MTTCG is done as I think the next wins are going to be in code generation and optimization. >> * 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. The eternal problem ;-) I'll send an email to my old employer and see if the unit tests can be liberated. The worst that could happen is they say no. > > > r~ -- Alex Bennée
