search for: xmm0_64

...(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 scenario there. On...

...it 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

...; 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

...o 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 dif...

...ution. > 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 things like AVX which applies the GPR aliasing scheme to vectors? I think this is the right way to go but we need to do things in a comprehensive way so we can expand as needed. -Dave

On Sep 24, 2008, at 9:15 AM, David Greene wrote: > >> 1. Treat these instructions as cross register class copies. The src >> and dst classes are different (VR128 and FR32) but "compatible". > > This seems reasonable. > >> 2. Model it as extract_subreg which coalescer can eliminate. >> >> #2 is conceptually correct. The problem is 128 bit XMM0 is

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 >

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 > >