search for: xmm0_32

...lem is 128 bit XMM0 is the same > register as 32 bit (or 64 bit) XMM0. So it's not possible to define > the super-register / sub-register relationship. I don't understand the problem with subregs here. Is it just a naming issue? That can be solved by introducing alternate names, like XMM0_32 and XMM0_64, for each of the subregs. They could still be printed as "xmm0" in the assembly output of course. Dan

...er as 32 bit (or 64 bit) XMM0. So it's not possible to define >>> the super-register / sub-register relationship. >> >> I don't understand the problem with subregs here. Is it just a >> naming issue? That can be solved by introducing alternate names, >> like XMM0_32 and XMM0_64, for each of the subregs. They could >> still be printed as "xmm0" in the assembly output of course. > > this is what the PPC64 backend does. "X0" (64-bit GPR) and "R0" (32- > bit GPR) both print as "r0". Somewhat different scenar...

...same >> register as 32 bit (or 64 bit) XMM0. So it's not possible to define >> the super-register / sub-register relationship. > > I don't understand the problem with subregs here. Is it just a > naming issue? That can be solved by introducing alternate names, > like XMM0_32 and XMM0_64, for each of the subregs. They could > still be printed as "xmm0" in the assembly output of course. this is what the PPC64 backend does. "X0" (64-bit GPR) and "R0" (32- bit GPR) both print as "r0". -Chris

...bit) XMM0. So it's not possible to define >>>> the super-register / sub-register relationship. >>> >>> I don't understand the problem with subregs here. Is it just a >>> naming issue? That can be solved by introducing alternate names, >>> like XMM0_32 and XMM0_64, for each of the subregs. They could >>> still be printed as "xmm0" in the assembly output of course. >> >> this is what the PPC64 backend does. "X0" (64-bit GPR) and "R0" (32- >> bit GPR) both print as "r0". > >...

...The pattern doesn't know if the rest of the vector is going to be used elsewhere so we need dataflow information and that implies it needs to be done in the coalescer (or some other transformation pass). > After thinking about this some more, I think #2 is a better solution. > Adding XMM0_32 etc. teaches codegen that only lower 32-bits of the > registers are used. Perhaps this can open up additional optimization > opportunities. On the other hand, adding these registers means > introducing more aliasing which has compile time implication. What about XMM0_64? What about thing...

...ink that would work. We still have to model the value as being produced by an instruction. So either we have to select it to a target specific instruction or a target independent instruction (i.e. extract_subreg). After thinking about this some more, I think #2 is a better solution. Adding XMM0_32 etc. teaches codegen that only lower 32-bits of the registers are used. Perhaps this can open up additional optimization opportunities. On the other hand, adding these registers means introducing more aliasing which has compile time implication. Evan > > >...

On Wednesday 24 September 2008 02:10, Evan Cheng wrote: > > I wrote a pattern that looks something like the above in form, but how > > do I tell the selection DAG to prefer my pattern over another that > > already exists. I can't easily just disable that other pattern > > because > > it generates Machine Instruction opcode enums that are assumed to be > >

Yes, Another reason this is useful is for register-type specific representations of said register. For example, all my registers 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

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 >