Qifei Fan wrote: > > But insn#479 is not recognized by recog() in insn-recog.c and the > > compilation failed. (recog only recognizes RTL defined in md, right?) > > Here the backtrace is > > reload--->cleanup_subreg_operands--->extract_insn_cached--->extract_insn-= > -->recog_memoized--->recog. > > There is no machine instruction(r3=3Dr1*4+r2) match the pattern of > > insn#479. Though there is pattern r3=3Dmem(r1*4+r2). > > I don=92t quite understand the generation of reload information.
There's two issues here. The first issue is that reload makes the fundamental assumption that everything that is a valid address, can be loaded into a register as well, if necessary. On many platforms this is true, either because there is some sort of "load address" instruction, or because the form of valid addresses matches standard arithmetic instruction patterns. Reload will simply emit a naked "set" of some register to the address -- if the back-end doesn't support that, you'll get the failure you saw. If this doesn't work on your particular platform, you could either try to set things up so that reload never thinks it needs to reload an address (but this may be difficult to achieve). The safe option would be to tell reload how to achieve computing an address by providing a "secondary reload" pattern. See e.g. s390_secondary_reload (in config/s390/s390.c) and the associated "reload<mode>_plus" pattern. The second issue is as you notice here: > Actually the second reload is not needed if there is already the first relo= > ad. > If (plus:SI (reg/f:SI 16 SP) (const_int 96 [0x60]) is replaced by > (reg:SI 12 a12), then (plus:SI (mult:SI (reg:SI 9 a9 [204]) > (const_int 4 [0x4])) (reg:SI 12 a12) ) is a valid memory address. > But in function find_reloads, I can=92t find the related code that > deciding whether the second reload should be generated by regarding > the previous reload. The function is too complex. :-( The first reload, loading sp + 96 into a register, is generated from within find_reloads_address. After this is done, it is assumed that the address is now valid. However, something else later in find_reloads apparently assumes there is still some problem with the operand, and decides to reload the whole address. It is hard to say exactly what the problem is, without seeing the insn constraints, but the most likely cause seems to be that this instruction pattern does not have a general "m" constraint, but a more restricted memory constraint. If this is the case, the back-end procedure called to verify the constraint probably rejects it. This runs into another fundamental assumption reload makes: it assumes such procedures take other actions done by reload into account implicitly. This means the constraint checker ought to *accept* addresses of the form reg*const + (sp + const) because it ought to know that reload will already load the (sp + const) into a register anyway. If this is *not* the case, please send me the instruction pattern and constraints for the insn pattern that matched insn 320 before reload so I can investigate in more detail. (Please note that I'm currently travelling with restricted access to email, so it might be a couple of days before I'm able to reply; sorry ...) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
