This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: expr.c: don't assume MUL for scaling pointers
- From: Richard Henderson <rth at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 03 Nov 2011 13:19:00 -0700
- Subject: Re: expr.c: don't assume MUL for scaling pointers
- References: <201111030323.pA33Nm9W029413@greed.delorie.com>
On 11/02/2011 08:23 PM, DJ Delorie wrote:
> GCC assumes the target has a multiply insn, but better code is
> generated using shifts if it doesn't (vs a libcall). Found with the
> rl78-elf port.
>
> * expr.c (expand_expr_real_2): Don't try to emit a MUL-based
> expression if the target doesn't have a multiply pattern. Fall
> back to shifts instead of using libgcc calls.
>
> Index: gcc/expr.c
> ===================================================================
> --- gcc/expr.c (revision 180758)
> +++ gcc/expr.c (working copy)
> @@ -8289,12 +8289,13 @@ expand_expr_real_2 (sepops ops, rtx targ
> }
>
> /* Attempt to return something suitable for generating an
> indexed address, for machines that support that. */
>
> if (modifier == EXPAND_SUM && mode == ptr_mode
> + && optab_handler (smul_optab, mode) != CODE_FOR_nothing
This is the wrong place for this. With EXPAND_SUM we're expecting
to generate something that is applicable to addresses, and the
addressing form is canonically (plus (mult x n) y).
This does suggest, though, that something ought to be using
expand_mult and not expand_simple_binop.
It's not immediately obvious what that something is, since my first
guess was force_operand and it *does* use expand_mult.
r~