> On 7/2/26 3:21 PM, Jose E. Marchesi wrote:
>> static bool
>> -bpf_rtx_costs (rtx x ATTRIBUTE_UNUSED,
>> +bpf_rtx_costs (rtx x,
>> enum machine_mode mode ATTRIBUTE_UNUSED,
>> - int outer_code ATTRIBUTE_UNUSED,
>> + int outer_code,
>> int opno ATTRIBUTE_UNUSED,
>> - int *total ATTRIBUTE_UNUSED,
>> + int *total,
>> bool speed ATTRIBUTE_UNUSED)
>> {
>> - /* To be written. */
>> + switch (GET_CODE (x))
>> + {
>> + case CONST_INT:
>> + {
>> + HOST_WIDE_INT val = INTVAL (x);
>> + /* BPF ALU instructions take a signed 32-bit immediate operand. */
>> + bool imm32 = (val == (HOST_WIDE_INT) (int32_t) val);
>> I would prefer if you would define a BPF_IMM32 macro in bpf.h and then
>> use it as well in the imm32_operand predicate in predicates.md.
>
> OK.
I forgot the _P in the suggested name. It shall be BPF_IMM32_P.
>
>>> + switch (outer_code)
>>> + {
>>> + /* Do not report a free constant when it is the operand of a
>>> + multiply, divide or modulo. A zero-cost constant misleads
>>> + synth_mult () and expand_divmod () into implementing the
>>> + operation as a sequence of shifts/adds (or a magic-number
>>> + multiply) instead of BPF's native single-instruction mul/div,
>>> + which is cheaper here. */
Been looking at expand_divmod, expmed_mult_highpart, choose_mult_variant
and friends to see why they would get misled when the cost of
div/udiv/mod with a constant op is COSTS_N_INSNS (1), and not when the
cost is CONSTS_N_INSNS (2). No success yet.. Do you know what is the
cause? Which div/mod tests are regressing?
Thanks.
