Re: Help-The possible places where insn is splitted in greg pass

[fanqifei <fanqifei at gmail dot com>]

2010/1/27 fanqifei <fanqifei@gmail.com>:
> 2010/1/25 Ulrich Weigand <uweigand@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.Weigand@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