On 4 December 2013 00:48, Richard Henderson <rth@xxxxxxxxxxx> wrote: > On 12/04/2013 01:32 PM, Peter Maydell wrote: >> You're right that we can just make this function return the TCGv >> temp rather than making the caller pass one in. Are you suggesting >> the 64-bit case should return cpu_X[reg] rather than a copy of it, >> though? I think it would be pretty hard to reason about if you had to >> remember that sometimes you got a trashable copy and sometimes >> the real register. > > I think that the normal case is to write to the output in one step, and thus > having an input overlap an output isn't your problem but tcg's. I would think > the case of multi-step output to be fairly rare, and easily solvable by always > allocating an output temporary. Does a copy to temp actually cost us anything, though? I was under the impression the TCG optimizer would basically throw it away again. I suppose you could just treat the semantics of it as "assume you can't trash this TCGv" in all cases and rely on the auto-free. > Am I off-base on the multi-output thing? Modulo flags setting, of course, but > I think that special case ought to be relatively solvable. > >> (I'm still a bit on the fence about that pool of auto-freeing temporaries. >> Manual temp management is certainly a fertile source of decoder bugs, >> but in the longer term we might want to push the functionality down into >> the common code rather than having an ad-hoc thing in one decoder.) > > See also Sparc and S390. ;-) Ah, I hadn't noticed we were already doing this in other frontends. -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
