|
From: Florian K. <br...@ac...> - 2012-02-19 18:36:21
|
On 02/19/2012 12:44 PM, Julian Seward wrote: > >>> One way to mostly get what you want is to suppress your optimisation >>> just for the first PUT(IP) = ... in the block (iow, make sure the >>> first is always an 8 byte PUT). After that you should be safe. I don't >>> know if you can do this without changing the the generic interface >>> used by guest_bb_to_IR.c to call the guest-specific insn disassemblers. >> >> Exactly, that is what I had coded up. > > So .. did you arrive at something which works reliably? (is unclear > from your mail) > Yes. Making the first PUT(IP) in an IRSB an 8-byte PUT solved the problem. I did not run a full regtest after that but would not expect any surprises. >> I had something similar in mind, namely to track the contents of certain >> guest state entries: IA and condition code thunk. The rationale is that >> newer s390's have an insn to add an 8-bit immediate to a storage >> location. So an update of the guest_IA is a single insn in most cases. >> No register being used. >> >> Binding the guest_IA to a temp creates a loooong lifetime which the >> register allocator will not like... > > Well, it all depends, right? That's the compiler-writing game. Yes. But: > The add-8-bit-immediate is going to give one load-op-store triple > per update, No. I was perhaps unclear. The instruction I have in mind to update the guest state operates on memory directly. There is not going to be a load-op-store triple. Now, to do that I need to add a new insn to the insn selector, namely: add this value to the guest state at offset so-and-so. That should be a clear win at least for IA because that value is almost never read. For the condition code thunk the jury is out. If the PUT doesn't create a temporary the next GET will access memory instead of the temporary. Will have to see how often that happens. Florian |