On Thu, 20 Mar 2008, Bernd Schmidt wrote: > Joseph S. Myers wrote: > > 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. > > Let me ask a stupid question. Do you need to use the rtx code SUBREG for this > at all, or would an UNSPEC work just as well? In other words, do these > SUBREGs appear in other insns, or are they restricted to just these patterns?
As I recall, these SUBREGs are what's generated by the core compiler. If they are generated in the rs6000 back end, the code generating them applies for non-SPE as well (and SPE conditionals in the rs6000 back end are avoided where possible) - but for non-SPE they would end up reducing to plain regs. So, these patterns need to match whatever RTL is generated elsewhere in the compiler. Hypothetically the compiler might be changed no longer to generate the RTL these patterns match, but this shouldn't be done in a way that adds SPE conditionals unnecessarily. I do not think SPE code generation is particularly good; it's certainly possible that different implementations of these patterns or different RTL would lead to better RTL optimization and better code (though I doubt UNSPECs would be particularly good for optimizability). I do, however, think these patterns work reliably in the compiler at present (but they were written to generate working code, not necessarily efficient code). -- Joseph S. Myers [EMAIL PROTECTED]
