------- Additional Comments From stuart at apple dot com 2004-12-02 01:07 ------- Jan emailed this to me privately. Appended here for completeness. - stuart ---------------------------------------------------------------- Just to clarify things a bit. TARGET_MOVX and TARGET_PARTIAL_REG_DEPENDENCY is not about supporting some feature but about a way the CPU deals with dependencies on partial registers. Some CPUs (Athlon+,P4+) deal with partial register writes as read-modify operation of the whole thing (TARGET_PARTIAL_REG_DEPENDENCT) and for some of these it is profitable to do dummy zero extend (TARGET_MOVX) instead of loads to avoid the dependency, while others (K6, P3) give it another internal name and don't see the false dependency (TARGET_PARTIAL_REG_STALL). On the other hand they get penalty if the result is used as a whole register. There is unlikely to be ever CPU spoiled up in both directions..
However the Roger's patch, as I understand it, is about avoiding movx as it encodes longer on -Os. It seems to me that for targets not defining TARGET_PARTIAL_REG_STALL/TARGET_PARTIAL_REG_DEPENDENCY we should always produce the straighforward movq as expected, while for TARGET_PARTIAL_REG_STALL/TARGET_PARTIAL_REG_DEPENDENCY we can still use the full moves as long as they don't encode longer. I can't check right now, but i believe it is only the movl imm, register that comes out longer and that is the alternative 2. We can also probably kill the TARGET_QIMODE_MATH as it is no longer used. There is the type and mode argument not only to choose the particular instruction but also to drive scheduling (K6 for instance has limited supply of units that do 8bit operations). imovx is 32bit operation so it needs to get SImode. I would simply break out the alternative 2 from both conditionals and would additionally check optimize_size to be nonzero I can prepare patch later next week unless someone beats me :) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
