2010/1/27 fanqifei <fanqi...@gmail.com>: > 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 > I have modified the constraint checker in which previous generated reloads are considered. Now the error is gone, from the result of reload I can see that the reload is correct. However the instruction is not in the final assembly code. It may be optimized away. So I am not sure this change is really correct.
-Qifei Fan
