This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: subreg rtl documentation


Usually, when a subreg appears in an insn pattern, it means that we
don't care if the value is sign or zero or otherwise extended.  For
instance, in the s390.md file, I see
  [(set (reg CC_REGNUM)
        (compare (ashiftrt:DI (ashift:DI (subreg:DI (match_operand:SI 0
"register_operand" "d") 0)
                                         (const_int 32)) (const_int 32))
                 (match_operand:DI 1 "const0_operand" "")))

You are right. And indeed this example is that the match_operand does not accept MEMs. What I was looking for (in h8300 and s390) was subreg.*memory as in

  [(set (match_operand:DI 0 "register_operand" "=d")
        (and:DI (subreg:DI (match_operand:SI 1 "memory_operand" "m") 0)
                (const_int 2147483647)))]

Now, these are indeed not as bad as having subregs of mems generated by combine according to LOAD_EXTEND_OP, and matched by register_operands only to require a subreg later. I now think we can avoid treating subregs of mems as anathema, *if* we get rid of the special casing in combine and possibly of LOAD_EXTEND_OP itself. After this is done, we could even try not recognizing subregs of mems as valid register_operands, and see what happens.

Paolo

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]