This is the mail archive of the gcc@gcc.gnu.org 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: Legitimize address after reload


David Guillen <david@davidgf.net> writes:
> So far I'm still facing problems regarding memory addresses even with
> the most restrictive conditions. The non-recognized instruction is:
>
> ../../../libgcc/libgcc2.c: In function '__muldi3':
> ../../../libgcc/libgcc2.c:559:1: error:  insn not satisfying its restrictions:
> (insn 130 164 134 4 (set:SI (mem/c:SI (plus:SI (mem/f/c:SI (plus:SI
> (reg/f:SI 6 %ebp)
>                         (const_int 8 [0x8])) [6 .result_ptr+0 S4 A32])
>                 (const_int 4 [0x4])) [2 <retval>+4 S4 A32])
>         (reg:SI 1 %edx [84])) ../../../libgcc/libgcc2.c:558 9 {*movsi}
>      (nil))
> ../../../libgcc/libgcc2.c:559:1: internal compiler error
> reload_cse_simplify_operands, at postreload.c:403
>
> I'm using this as TARGET_LEGITIMATE_ADDRESS_P:
>
> bool valid_address (enum machine_mode mode, rtx x, bool strict_p) {
>   switch (GET_CODE (x)) {
>     case REG:
>     case SUBREG:
>       return REG_P(x);
>     case PLUS:
>       return ( REG_P( XEXP(x,0) ) && CONST_INT_P( XEXP(x,1) ) );
>     case CONST_INT:
>     case CONST:
>     case LABEL_REF:
>     case SYMBOL_REF:
>       return true;
>     default:
>       return false;
>     }
> }
>
> So I don't get why the reload pass doesn't force the address to be in
> a register.
>
> Any ideas?
> And, anyone can give me a hint on how to debug this issues? I'd like
> to discover where in the gcc source this memory RTX expression is
> created and why it is not expanded to be a valid address.

What DJ meant below was that you should reject all pseudo registers
if strict_p.  I.e. REG_P (foo) should be:

   REG_P (foo) && (!strict_p || REGNO_MODE_OK_FOR_BASE_P (foo, mode))

where REGNO_MODE_OK_FOR_BASE_P should only accept hard registers and
where "mode" is the mode of the memory being accessed.

Thanks,
Richard

> 2014-03-14 18:56 GMT+01:00 DJ Delorie <dj@redhat.com>:
>>
>> David Guillen <david@davidgf.net> writes:
>>> In any case I'm not using the restrict variable and I'm assuming
>>> strict is zero, this is, not checking the hard regsiters themselves.
>>> This is because any reg is OK for base reg. I'm pretty sure I'm
>>> behaving similarly to arm, cris or x86 backends.
>>
>> "strict" doesn't mean which hard register it is, "strict" means whether
>> or not it's a hard register at all.
>>
>> If "strict" is true, you must assume any REG which isn't a real hard
>> register (i.e. REGNO >= FIRST_PSEUDO_REGISTER) does NOT match.


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