On Thu, 20 Mar 2008, Bernd Schmidt wrote: > Paolo Bonzini wrote: > > SPE has patterns for > > > > [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m") > > (subreg:SI (match_operand:SPE64TF 1 "register_operand" "r,r") 4))] > > > > for example. > > What are they trying to do? It's dubious for a number of reasons: > - SUBREG in the instruction pattern means that we'll eventually end up with > SUBREG of a hard register
Yes. For SPE, the subregs used in these *frob_* patterns represent concepts including the high-part of a register (only used by certain instructions that treat registers as 64 bits) and a DImode value stored in one 64-bit register (normal layout is in two) or a DFmode value on E500v2 stored in the low parts of two registers (normal layout is in one register). That is, the subregs of hard registers cannot be represented as single regs because they represent data laid out in registers in a different way from how a single reg in that mode is interpreted. This works fine given the subreg_info infrastructure I added. > - Any insn that matches this pattern would also match movsi These insn patterns are here precisely because the compiler generates such patterns that do not match generic patterns in rs6000.md. Thus, they are needed to match the RTL the compiler generates. > - There shouldn't really be multiple movsi patterns There seem to be quite a lot of *movsi_* patterns in rs6000.md, matching different sorts of RTL generated by the compiler. These are more such patterns that happen to have different names; it doesn't matter whether a pattern's name starts *movsi or *frob. -- Joseph S. Myers [EMAIL PROTECTED]
