Re: Revision 107218 changed addressing mode generation

[Christian BRUEL <christian dot bruel at st dot com>]

hello,

Looks like a similar problem, or at least related, than the one I 
addressed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423 ?

-c

Bernd Schmidt wrote:
> Revision 107218, which introduced fold_plusminus_mult_expr, changed the 
> way we are folding certain constants.
>
> Breakpoint 7, fold_plusminus_mult_expr (code=PLUS_EXPR, type=0xb7b0c000, 
> arg0=0xb6b8ebd0, arg1=0xb6b8c7a8)
> 7389    {
> (gdb) p arg0
> $48 = (tree) 0xb6b8ebd0
> (gdb) pt
>  <mult_expr 0xb6b8ebd0
>     type <integer_type 0xb7b0c000 long unsigned int public unsigned 
> sizetype SI
>         size <integer_cst 0xb7afc444 constant invariant 32>
>         unit size <integer_cst 0xb7afc230 constant invariant 4>
>         align 32 symtab 0 alias set -1 canonical type 0xb7b16270 
> precision 32 min <integer_cst 0xb7afc4d0 0> max <integer_cst 0xb7afc9bc 
> -1>>
>
>     arg 0 <bit_and_expr 0xb6b8ebac type <integer_type 0xb7b0c000 long 
> unsigned int>
>
>         arg 0 <nop_expr 0xb69845c0 type <integer_type 0xb7b0c000 long 
> unsigned int>
>             arg 0 <var_decl 0xb6b8d9f8 work.384>>
>         arg 1 <integer_cst 0xb723f40c constant invariant 63>> arg 1 
> <integer_cst 0xb7afc230 4>>
> (gdb) p arg1
> $49 = (tree) 0xb6b8c7a8
> (gdb) pt
>  <integer_cst 0xb6b8c7a8 type <integer_type 0xb7b0c000 long unsigned 
> int> constant invariant 1792>
>
> Instead of generating a PLUS around the MULT, this falls into the last 
> arm of the if statement (with the maybe_same code) and produces a MULT 
> of a PLUS.  This behaviour is different from what fold-const did in 4.1. 
>  In some cases, the new code causes less efficient addressing modes to 
> be generated on the Blackfin.
>
> I can make the problem go away with the patch below.  Richard, is that 
> maybe what you originally intended here?
>
>
> Bernd