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


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 <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]