search for: xy00

...rs are 128bit vector registers, however, if I am only dealing with 32 bit vector registers, I can add write/read masks that tell the underlying hardware not to work on the whole register, but just a subset of the components. 32bit scalar mov: mov r1.x___, r0.x000 64bit scalar mov: mov r1.xy__, r0.xy00 96bit scalar mov: mov r1.xyz_, r0.xyz0 128bit scalar mov: mov r1, r0 If I had the register type information at code generation time, then I can use the exact same tablegen pattern for all my register types and would only need to add the write/read masks in the printer instead of multiple patterns...

On Wednesday 24 September 2008 15:23, Mon Ping Wang wrote: > To my knowledge, I don't think there is an easy way to get the MVT > information from a MachineOperand. Why do you need it for? In my See the thread I started on this very topic. Spilling is one place you'd like to have this information. > mind, the MachineInstr and its associated operands represent a >

..., r4, r5 mov r3.x, r101 (float4 => float1 extract_vector_elt) iadd r6.xy__, r0.x000, r3.0x00(float1 + float1 => float2 build_vector) dp4 r7.x, r8, r9 <as above> dp4 r10.x, r11, r12 <as above> iadd r13.xy__, r7.x000, f10.0x00(float1 + float1 => float2 build_vector) iadd r14, r13.xy00, r6.00xy (float2 + float2 => float4 build_vector) sub r15, r14, r9 It's not as compact and neat but it works and the move instructions will get optimized away by the lower level gpu compiler. Hope this helps, Micah -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:l...

Evan Cheng-2 wrote: > > Well, how many possible permutations are there? Is it possible to > model each case as a separate physical register? > > Evan > I don't think so. There are 4x4x4x4 = 256 permutations. For example: * xyzw: default * zxyw * yyyy: splat Even if can model each of these 256 cases as a separate physical register, how can I model the use of r0.xyzw in