On Dec 10, 2015 12:40 PM, "Matt Turner" <<a href="mailto:mattst88@gmail.com">mattst88@gmail.com</a>> wrote: > > On Thu, Dec 10, 2015 at 11:11 AM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > > > > On Dec 10, 2015 6:58 AM, "Francisco Jerez" <<a href="mailto:currojerez@riseup.net">currojerez@riseup.net</a>> wrote: > >> > >> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes: > >> > >> > We aren't using it anymore. > >> > >> It seems useful to me to be able to represent indirect access as part of > >> any instruction source or destination register. > >> > >> The following: > >> > >> | mov_indirect g0, g1, a0 > >> | foo g2, g0 > >> > >> and the converse case with indirect destination offset (which you don't > >> seem to represent currently) can be implemented by the hardware more > >> efficiently using a single instruction in certain cases. The current IR > >> is able to represent what the hardware can do, but supporting the > >> MOV_INDIRECT instruction only would force us to keep the indirection > >> separate from the instruction that uses it, so it seems like a less > >> expressive representation to me than the current approach, unless you're > >> willing to add _INDIRECT variants of most hardware opcodes. > > > > Yes and, mostly, no. Yes, you can put an indirect on almost anything but it > > has substantial restrictions: > > > > 1) Destination indirects must be uniform (I'm only 95% sure this is the > > case) > > Almost true. The Register Region Restrictions page gives an example: > > > // Example: > > mov (16) r[a0.0]:f r10:f > > // The above instruction behaves the same as the following two instructions: > > mov (8) r[a0.0]:f r10:f > > mov (8) r[a0.1]:f r11:f > > But that's all you get -- you still have to use 1x1 mode. > > And that behavior changes on BDW: > > > // Example: > > mov (16) r[a0.0]:f r10:f > > // The above instruction behaves the same as the following two instructions: > > mov (8) r[a0.0]:f r10:f > > mov (8) r[a0.0, 8*4]:f r11:f > > > The BRW_VERTICAL_STRIDE_ONE_DIMENSIONAL (0xF) vertical stride is > necessary for Vx1 or VxH, and the destination does not have vertical > stride. It's also not usable in align16 mode or on src1. Thanks for digging up the details. That all makes sense and is still insane. --Jason