This is the mail archive of the gcc-patches@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: Patch (rs6000): fix codegen for lod/sto to double at offset 32760


	Your patch causes regressions on AIX, and predumably PPC64 Linux
as well.  rs6000_legitimate_offset_address_p() does not recognize TOC
addresses as valid, so when presented with, for example,

(mem/u:DF (plus:SI (reg:SI 2 2)
        (const:SI (minus:SI (symbol_ref/u:SI ("*LC..0") [flags 0x2])
                (symbol_ref:SI ("*LCTOC..1"))))) [3 S8 A64])

the function returns false and movdf_hardfloat32 emits the address
compensation code on a non-indexed form address, which produces
inefficient and invalid assembly.

	I am testing a fix using legitimate_constant_pool_address_p():

    if (!INT_REG_OK_FOR_BASE_P (XEXP (x, 0), strict))
      return false;
+   if (legitimate_constant_pool_address_p (x))
+     return true;
    if (GET_CODE (XEXP (x, 1)) != CONST_INT)
      return false;

	The one thing I am a little worried about, and would like Geoff's
opinion, is legitimate_constant_pool_address_p() tests

  return (TARGET_TOC
          && GET_CODE (x) == PLUS
          && GET_CODE (XEXP (x, 0)) == REG
          && (TARGET_MINIMAL_TOC || REGNO (XEXP (x, 0)) == TOC_REGISTER)
          && constant_pool_expr_p (XEXP (x, 1)));

and constant_pool_expr_p() returns

    case CONST_INT:
      return 1;

so it I think any (plus (reg) (const_int)) is considered valid when
TARGET_MINIMAL_TOC is enabled.

	I do not understand why legitimate_constant_pool_address_p() tests
TARGET_MINIMAL_TOC when TOC_REGISTER implicitly is set to the correct TOC
register. 

David


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