Re: [PATCH RFC] Finer grained reg classes.
David Miller writes: > So this patch tries to rework the semantics of hard register classes, > such that if a hard register is present in the set it is implied that > the rest of the registers in a multi-register group are present as > well. So we can add a register class called EVEN_REGS and only have > to set the even register bits. It would be great if this could be made to work. I think the main problem is going to be stopping registers from other register files being included accidentally. E.g. if on a 32-bit target you store a 128-bit value in an even GPR, using the GPR class itself ensures that all four registers are GPRs. The last even GPR is automatically disallowed. If instead we say that only the first register needs to belong to the class, I assume we'd need both an EVEN_REGS and an EVEN_REGS_EXCEPT_... class. I must admit I don't really understand why HARD_REGNO_MODE_OK() is a problem for IRA and LRA. Although they work on register classes, most of the internal calculations are done on register sets, which can be masked as needed. E.g. ira_prohibited_class_mode_regs already takes HARD_REGNO_MODE_OK() into account. And even if the register class itself only gives the first register, all the conflict calculations are still going to need to include all registers. I'm probably repeating a previous discussion here, sorry. Richard
Re: [PATCH RFC] Finer grained reg classes.
On Tue, Mar 19, 2013 at 7:31 PM, Jeff Law wrote: > On 03/19/2013 11:58 AM, Ian Lance Taylor wrote: >> >> On Tue, Mar 19, 2013 at 8:33 AM, David Miller wrote: >>> >>> >>> So this patch tries to rework the semantics of hard register classes, >>> such that if a hard register is present in the set it is implied that >>> the rest of the registers in a multi-register group are present as >>> well. So we can add a register class called EVEN_REGS and only have >>> to set the even register bits. >> >> >> I haven't really looked at your patch, but I just want to say that I >> think this is the right way to go. > > Likewise. I've certainly worked on ports where this would have been helpful > in the past. It could also help simplify existing ports. rs6000 has a few places where this could be useful (dfp). At least arm (VFP_REGNO_OK_FOR_DOUBLE), avr, and h8300, too. And ISTR s390 plays funny subreg tricks to get this right. Finally, it's been discussed on the gcc@ mailing list for out-of-tree ports a few times in recent history. So yes, great if this can be done! Ciao! Steven
Re: [PATCH RFC] Finer grained reg classes.
On 03/19/2013 11:58 AM, Ian Lance Taylor wrote: On Tue, Mar 19, 2013 at 8:33 AM, David Miller wrote: So this patch tries to rework the semantics of hard register classes, such that if a hard register is present in the set it is implied that the rest of the registers in a multi-register group are present as well. So we can add a register class called EVEN_REGS and only have to set the even register bits. I haven't really looked at your patch, but I just want to say that I think this is the right way to go. Likewise. I've certainly worked on ports where this would have been helpful in the past. Jeff
Re: [PATCH RFC] Finer grained reg classes.
On Tue, Mar 19, 2013 at 8:33 AM, David Miller wrote: > > So this patch tries to rework the semantics of hard register classes, > such that if a hard register is present in the set it is implied that > the rest of the registers in a multi-register group are present as > well. So we can add a register class called EVEN_REGS and only have > to set the even register bits. I haven't really looked at your patch, but I just want to say that I think this is the right way to go. Ian
