2010/1/25 Ulrich Weigand <uweig...@de.ibm.com>: > 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 >
For the second issue, there is indeed a strict constraint(back-end procedure) that rejects the pattern. The back-end procedure is composed of macros like EXTRA_MEMORY_CONSTRAINT/EXTRA_CONSTRAINT. These macros are defined in config/cpu.c and used in around Line3376 of reload.c(gcc4.3.2). So it's the constraint checker's job to know whether reload will load the (sp+const) into a register and use such information to decide whether to accept the pattern or not, right? Is there any other architecture which checks address by using previous determined reload info? I think this may be the proper way to resolve this problem. It may be easy to implement too. I will dig into all the issues and possible options, and provide more information later. As I am not familiar with it, it may take some time. Thanks very much!! -Qifei Fan
