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 ICE caused by lax rs6000_legitimize_address


On Mon, Nov 10, 2008 at 11:14 PM, Nathan Froyd <froydnj@codesourcery.com> wrote:
> The patch below fixes a mismatch between what rs6000_legitimize_address
> generates and what rs6000_legitimate_address_p expects.  REG+OFFSET
> addressing on ppc64 requires that OFFSET be word-aligned;
> rs6000_legitimate_address_p checks for that, rs6000_legitimize_address
> did not.
>
> The fix is straightforward enough; I think the check for DDmode is
> right, although I don't have a hard decimal-float machine to test on.
> Testing in progress on powerpc64-unknown-linux-gnu.  OK to commit during
> stage 3, or should this wait for 4.5?

> Index: gcc/config/rs6000/rs6000.c
> ===================================================================
> --- gcc/config/rs6000/rs6000.c  (revision 141763)
> +++ gcc/config/rs6000/rs6000.c  (working copy)
> @@ -3816,7 +3816,14 @@ rs6000_legitimize_address (rtx x, rtx ol
>       high_int = INTVAL (XEXP (x, 1)) - low_int;
>       sum = force_operand (gen_rtx_PLUS (Pmode, XEXP (x, 0),
>                                         GEN_INT (high_int)), 0);
> -      return gen_rtx_PLUS (Pmode, sum, GEN_INT (low_int));
> +      /* Using a REG+CONST 64-bit integer load on 64-bit platforms
> +        requires that CONST be word-aligned.  */
> +      if (TARGET_POWERPC64
> +         && (mode == DImode || mode == DDmode)
> +         && (low_int & 0x3))
> +       return gen_rtx_PLUS (Pmode, sum, force_reg (Pmode, GEN_INT (low_int)));
> +      else
> +       return gen_rtx_PLUS (Pmode, sum, GEN_INT (low_int));
>     }
>   else if (GET_CODE (x) == PLUS
>           && GET_CODE (XEXP (x, 0)) == REG
>

I have no objection to this type of patch during stage 3.

Why create a [REG+REG] indexed form for these unaligned addresses
instead of including the low-order bits in the sum created immediately
prior?  I think the logic can be hoisted to adjust low_int and high_int for
PowerPC64.

Also, as Pinski mentioned, the testcase is not PowerPC-specific.

Thanks, David


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