|
From: Julian S. <js...@ac...> - 2012-11-07 12:17:04
|
On Wednesday, November 07, 2012, Florian Krohm wrote: > You could do the zero extension after the load, couldn't you? In which > case you wouldn't need the IRLoadGOp. > But representing it the way you propose gives you an advantage in insn > selection. Is that right? Or is there another reason? Just curious. The IRLoadGOp was a late addition to the plan, when I came to try it out for real on ARM. What ARM has is (eg) a conditional 8 bit load into a 32 bit register, with zero extension. One possibility would be to do a conditional 8 bit load with an 8-bit fallback value (if the load doesn't happen), but then there would be complicated IR logic to either zero extend the loaded value to 32 bits or merge the top 24 bits of the fallback value back on to the lower 8 bits, so the IR-level register remains unchanged. In the end it seemed simplest to simply combine the load and conversion. I could have used an IROp to indicate the conversion instead of using a new enum, but that seems unclean -- obviously almost all of the IROps one could put it are nonsensical -- and it would also require extending IROp with a 32-bit identity operation. So I did a new enum. Overall the new scheme is quite nice and allows isel (as you observe) to simply re-emit the conditional load directly (on ARM). > > On 11/05/2012 10:31 AM, Julian Seward wrote: > > Next step is to fix up all the tools to handle the changes. Might not > > be too easy, since many tools look at loads and stores but assume they > > are unconditional. > > Right. That reminds me that the guard on the dirty helper is also only > recognised in memcheck... One other thing I have been thinking about for a while, although haven't done anything about, is to relax the type rules for condition expressions (guards) in IRLoadG, IRStoreG, IRMux0X, IRDirty, IRExit. Currently they are require, respectively, I1, I1, I8, I1, I1. This is inconsistent, and worse, it leads to chains of pointless IR conversions, like 32to1(1Sto32(32to1(1Uto32(CmpNE32(x, 0)))) which are surprisingly common, especially in arm-derived IR. What I am contemplating is to change all of them to require a value of an integral type (I1, I8, I16, I32 or I64), and test zero/nonzero, a la C style conditionals. Then all the chains of conversions would disappear. It would require a bit more work in the insn selectors since they'd need to check the type of the expression before generating code for it, but that is no big deal. In an ideal world we could also swap the order of '0' and 'X' clauses in Mux0X, so it reads more like C's ?-: operator. But that's probably too big a change given that the reason is only one of aesthetics. J |