|
From: Julian S. <js...@ac...> - 2012-02-19 17:44:51
|
> > 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) > > Another way to get what you want is to put the cleverness in the back > > end instead. In the insn selector, keep track (perhaps in the ISelEnv) > > of which virtual regs have known constants. Then, when you see > > "PUT(...) = 64-bit constant", see if you can do it with > > > > rTemp = (selected vreg) + small constant > > *(rBaseblock + offs_IP) = rTemp > > 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. The add-8-bit-immediate is going to give one load-op-store triple per update, whereas having a reg with a long lifetime is gives only one op-store pair per update, plus some unknowable spill-restore cost if there's a lot of pressure on registers. Who knows which is better. J |