This is the mail archive of the 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: Ping #1: [Patch,AVR] Fix/hack around spill fail ICE PR52148

2012/2/25 Georg-Johann Lay <>:
> The pattern for the address spaces is now as simple as
> ;; $0 Â Â: Address Space
> ;; $1 Â Â: RAMPZ RAM address
> ;; R24 Â : #bytes and loop register
> ;; R23:Z : 24-bit source address
> ;; R26 Â : 16-bit destination address
> ;; "movmemx_qi"
> ;; "movmemx_hi"
> (define_insn "movmemx_<mode>"
> Â[(set (mem:BLK (reg:HI REG_X))
> Â Â Â Â(mem:BLK (lo_sum:PSI (reg:QI 23)
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â (reg:HI REG_Z))))
> Â (unspec [(match_operand:QI 0 "const_int_operand" "n")]
> Â (use (reg:QIHI 24))
> Â (clobber (reg:HI REG_X))
> Â (clobber (reg:HI REG_Z))
> Â (clobber (reg:QI LPM_REGNO))
> Â (clobber (reg:HI 24))
> Â (clobber (reg:QI 23))
> Â (clobber (mem:QI (match_operand:QI 1 "io_address_operand" "n")))]
> Â""
> Â"%~call __movmemx_<mode>"
> Â[(set_attr "type" "xcall")

Thanks for explanation.
This technique similar to mulhi3, mulhi3_call ...
IMHO this is a better solution then very strict constraint 'x' or 'y' or 'z'.
I.e. better to have (at least from reload's point of view):
mov r26, "r"
mov r27, "r"
r30,r31 = do-something-with r26, r27
mov "r", r30
mov "r", r31
"z" = do-something-with "x"


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