Re: RFC: LRA for x86/x86-64 [7/9] -- continuation

[Richard Sandiford <rdsandiford at googlemail dot com>]

I'm having to correct my own comments again, sorry.

Richard Sandiford <rdsandiford@googlemail.com> writes:
>> +  /* If this is post-increment, first copy the location to the reload reg.  */
>> +  if (post && real_in != result)
>> +    emit_insn (gen_move_insn (result, real_in));
>
> Nit, but real_in != result can never be true AIUI, and I was confused how
> the code could be correct in that case.  Maybe just remove it, or make
> it an assert?

Probably obvious, but I meant "real_in == result" can never be true.
"real_in != result" could be removed or turned into an assert.

>> +	if (GET_CODE (op) == PLUS)
>> +	  {
>> +	    plus = op;
>> +	    op = XEXP (op, 1);
>> +	  }
>
> Sorry, I'm complaining about old reload code again, but: does this
> actually happen in LRA?  In reload, a register operand could become a
> PLUS because of elimination, but I thought LRA did things differently.
> Besides, this is only needed for:
>
>> +	if (CONST_POOL_OK_P (mode, op)
>> +	    && ((targetm.preferred_reload_class
>> +		 (op, (enum reg_class) goal_alt[i]) == NO_REGS)
>> +		|| no_input_reloads_p)
>> +	    && mode != VOIDmode)
>> +	  {
>> +	    rtx tem = force_const_mem (mode, op);
>> +	    
>> +	    change_p = true;
>> +	    /* If we stripped a SUBREG or a PLUS above add it back.  */
>> +	    if (plus != NULL_RTX)
>> +	      tem = gen_rtx_PLUS (mode, XEXP (plus, 0), tem);
>
> and we shouldn't have (plus (constant ...) ...) after elimination
> (or at all outside of a CONST).  I don't understand why the code is
> needed even in reload.

Scratch the thing about needing it for reload.  It's obviously the
second second operand we're reloading, not the first, and it could
well be that an elimination displacement needs to be reloaded via
the constant pool.

The question for LRA still stands though.

Richard