Thanks for the information.
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.
Thanks a lot!
David
2014-03-14 18:56 GMT+01:00 DJ Delorie <d...@redhat.com>:
>
> David Guillen <da...@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.
