|
From: Julian S. <js...@ac...> - 2012-10-12 08:42:12
|
On Friday, October 12, 2012, Florian Krohm wrote: > Remember the guard expression on the dirty helper? Yes (sigh). > > At first I thought of having conditional loads as just another IRExpr > > member. But that gives potential complexity with register allocation > > if we allow arbitrary expressions for the "backup" value, since if the > > guard is false then we won't want any of the expression to be > > evaluated. > > Huh? I think you want to evaluate the backup expression if the guard is > false. No? My mistake (I wrote that at 2.30am). I meant "if the guard is true". > Just to be clear: in a Conditional_Load stmt both the address_expr and > the backup_temp get evaluated independent of the value of the guard > expression. Right? Yes, that's true. Since we don't have proper if-then-else control flow in the back ends, everything has to be always evaluated. If we did have proper if-then-else then we wouldn't need a separate conditional load stmt since we could make Mux0X lazy (like C's ?-: triop) and use that. But doing that would require major rework of the regalloc and code generation framework, and I'm not up for that much hassle right now. > You probably need to stick in the endianess into the Conditional_Load. Yes. > While we're at it... Can I have a Ist_PutC -- a conditional Put ? > > PutC ( guard_expr, offset, data_temp) > > If guard_expr is true, then data_temp will be stored at offset in guest > state. That would help s390. Hmm, I'd prefer not, unless you absolutely need it. What do you need it for? To represent conditional loads into a register I had planned to do tAddr = ... tGuard = ... tBackup = GET(offs) tRes = LoadC( tGuard, tAddr, tBackup ) PUT(offs) = tRes which probably isn't as bad as it seems if you assume that in-context (in the middle of a sequence of insns, one of which loads the target register before this, and one of which hopefully uses and then overwrites it later), the IR optimiser will remove both the GET (PUT-GET forwarding) and the PUT (redundant PUT removal). To some extent it's a question of "hack it up and then see if IRopt turns it into something reasonable, in common cases". J |