Robin Dapp <rdapp....@gmail.com> writes: >> But in the VLA case, doesn't it instead have precision 4+4X? >> The problem then is that we can't tell at compile time which >> byte that corresponds to. So... > > Yes 4 + 4x. I keep getting confused with poly modes :) > In this case we want to extract the bitnum [3 4] = 3 + 4x which > would be in byte 0 for x = 0 or x = 1 and in byte 1 for x = 2, 3 and > so on. > > Can't we still make that work somehow? As far as I can tell we're looking > for the byte range to be accessed. It's not like we have a precision or > bitnum of e.g. [3 17] where the access could be anywhere but still a pow2 > fraction of BITS_PER_UNIT. > > I'm just having trouble writing that down. > > What about something like > > int factor = BITS_PER_UINT / prec.coeffs[0]; > bytenum = force_align_down_and_div (bitnum, prec.coeffs[0]); > bytenum *= factor; > > (or a similar thing done manually without helpers) guarded by the > proper condition? > Or do we need something more generic for the factor (i.e. prec.coeffs[0]) > is not enough when we have a precision like [8 16]? Does that even exist?.
It's not just a question of which byte though. It's also a question of which bit. One option would be to code-generate for even X and for odd X, and select between them at runtime. But that doesn't scale well to 2+2X and 1+1X. Otherwise I think we need to treat the bit position as a variable, with bitpos % 8 and bitpos / 8 being calculated at runtime. Thanks, Richard
