On Mon, Aug 15, 2011 at 5:34 PM, Richard Sandiford
<richard.sandif...@linaro.org> wrote:
> Richard Guenther <richard.guent...@gmail.com> writes:
>> On Mon, Aug 15, 2011 at 5:15 PM, Richard Sandiford
>> <richard.sandif...@linaro.org> wrote:
>>> rtx_cost knows that the expression under test (X) is an operand to an
>>> expression of a particular code (OUTER_CODE). However, nothing says
>>> which operand it actually is. This can make a difference for
>>> non-commutative binary operations. E.g. shifts by 1 are often
>>> cheaper than shifts of 1.
>>>
>>> The patch below makes this information available. I'm planning on
>>> using this parameter to provide costs of lvalues as well as rvalues,
>>> but that's a separate patch.
>>>
>>> In the backend patches, I've avoided propagating the extra parameter
>>> to subroutines unless it would be used. I've also passed the original
>>> operand number to recursive calls wherever the original code is passed
>>> to recursive calls. This includes expressions of the form:
>>>
>>> rtx_cost (A, outer_code, speed_p) + rtx_cost (B, outer_code, speed_p)
>>>
>>> where A and B are subrtxes of X. Since X is exactly one operand,
>>> it seems odd to sum two costs with the same outer code like this,
>>> but I left it be.
>>>
>>> I notice that score defines an rtx cost function but doesn't
>>> actually use it. Again, I've not fixed that here.
>>>
>>> avr.c:final_prescan_insn passes a SET rtx to rtx_cost (with an
>>> outer code of INSN). This is only used for debugging, so I passed
>>> an arbitrary opno here. (I didn't pass the opno of PATTERN because
>>> that could easily change in future.)
>>>
>>> Tested on x86_64-linux-gnu. Also tested by compiling cc1 for:
>>>
>>> alpha-linux-gnu arm-linux-gnueabi avr-rtems bfin-elf cris-elf
>>> fr30-elf frv-linux-gnu h8300-elf ia64-linux-gnu iq2000-elf
>>> lm32-elf m32c-elf m32r-elf m68k-linux-gnu mcore-elf mep-elf
>>> microblaze-elf mips-linux-gnu mmix mn10300-elf moxie-elf
>>> hppa64-hp-hpux11.23 pdp11 picochip-elf powerpc-linux-gnu
>>> powerpc-eabispe rx-elf s390-linux-gnu score-elf sh-linux-gnu
>>> sparc-linux-gnu spu-elf xstormy16-elf v850-elf vax-netbsdelf
>>> xtensa-elf
>>>
>>> and checking that (a) there were no new warnings and (b) that the
>>> -O2 and -Os output for gcc.dg and gcc.c-torture didn't change.
>>> OK to install?
>>
>> Can you add to the documentation that operands are counted from zero?
>
> Sure. How about:
>
> The cost may depend on the precise form of the expression, which is
> available for examination in @var{x}, and the fact that @var{x} appears
> as operand @var{opno} of an expression with rtx code @var{outer_code}.
> That is, the hook can assume that there is some rtx @var{y} such
> that @samp{GET_CODE (@var{y}) == @var{outer_code}) and such that
> either (a) @samp{XEXP (@var{y}, @var{opno}) == @var{x}} or
> (b) @samp{XVEC (@var{y}, @var{opno})} contains @var{x}.
>
> @var{code} is @var{x}'s expression code---redundant, since it can be
> obtained with @code{GET_CODE (@var{x})}.
Yes, that looks good to me.
Thanks,
Richard.
