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})}.
> I suppose lvalues will be SET, 0 then, right?
I think it'd be easier to have negative opno mean "lvalue". The problem
is that things like zero_extend can be used as either lvalues or rvalues,
so if you're taking the cost of the operand of a zero_extend, you need to
know more than the operand number itself (which is always 0).
But that's for another day...
> THe patch looks ok to me but please leave others (esp. target maintainers)
> time to comment.
Thanks. I'll hold off till Thursday morning UK time.
Richard
