https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113695
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rdapp at gcc dot gnu.org
Blocks|120763 |
--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
This is roughly similar to limitations we have on addressing modes with side
effects (ie, auto-increment/decrement, pre/post modify). We disallow the same
register to be used in the address and outside the address. So for example,
assume a target with pre-decrement addressing. We can't do something like
store r1, @r1-
That's turned out to be bloody hard to enforce properly. Right now I only
believe the pdp11 port handles it correctly. H8 handles it for many, but not
all cases.
The only known way to handle this is to create a singleton register class for
each GPR used as an autoincrement address and a class which is all the GPRs
except one register. If we take the H8 has an example. Za..Zh are
autoincrement addresses using one known register (r0..r7). Z0..Z7 are classes
with all the GPRs except one. ie, Z0 has r1..r7, but not r0.
Given register classes like that, you then have multiple alternative contraints
where they pair up. So one alternative would have Za/Z0 another Zb/Z1 for the
operands in question:
(define_insn ""
[(set (match_operand:QI 0 "general_operand_dst"
"=rm,Za,Zb,Zc,Zd,Ze,Zf,Zh,Zg")
(subreg:QI (lshiftrt:HI (match_operand:HI 1 "register_operand"
"r,Z0,Z1,Z2,Z3,Z4,Z5,Z6,Z7")
(const_int 8)) 1))
(clobber (reg:CC CC_REG))]
""
"mov.b\\t%t1,%R0"
[(set_attr "length" "8")])
So when we choose alternative 1 (Za/Z0), we'll use an r0 as an autoincrement
addressing mode for the store and any register other than r0 can be the source
value.
That (of course) would be fairly painful to do on RISC-V as we have 32
registers. But as far as I know, it's the only way to handle this problem.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
[Bug 120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting
