----- Am 27. Dez 2025 um 0:43 schrieb Jeff Law [email protected]:

> On 12/7/2025 5:11 AM, Sebastian Huber wrote:
[...]
>> +
>> +    /* Get the high 32-bit of the counter */
>> +    tree shift_32 = build_int_cst (integer_type_node, 32);
>> +    tree counter_high_64 = make_temp_ssa_name (gcov_type_node, NULL,
>> +                                           "PROF_decision");
>> +    gassign *assign3 = gimple_build_assign (counter_high_64, LSHIFT_EXPR,
>> +                                        counter, shift_32);
> 
> Doesn't the type of shift_32 need to match the type of the object being
> shifted?  Or do we have loose requirements around type checking operands
> for this case (where the shift count is often in a smaller precision
> than the object being shifted).

This is my attempt to write something like this:

int shift_32 = 32;
gcov_type_node counter_high_64 = counter >> shift_32;

> 
> Do we need to worry about logical vs arithmetic shifts here? COUNTER's
> type is going to drive that decision, so we just need to make sure it's
> sensible.

We have

tree
get_gcov_type (void)
{
  scalar_int_mode mode
    = smallest_int_mode_for_size
      (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32).require ();
  return lang_hooks.types.type_for_mode (mode, false);
}

So, the gcov_type_node is probably a signed type.

With

    gassign *assign4 = gimple_build_assign (counter_high_32, NOP_EXPR,
                                            counter_high_64);

does it matter if it is a logical or arithmetic shift? I am sorry, but I don't 
really know what I am doing here. I tinkered this together by looking at 
examples in the code.

> 
> 
>>
>>
>> @@ -1157,6 +1213,11 @@ instrument_decisions (array_slice<basic_block> expr,
>> size_t condno,
>>                                                    next[k], relaxed);
>>                  gsi_insert_on_edge (e, flush);
>>              }
>> +            else if (use_atomic_split)
>> +            {
>> +                split_update_decision_counter (e, ref, next[k],
>> +                                               atomic_ior_32, relaxed);
>> +            }
> 
> Consider dropping the extraneous curlys.  That function seems to be
> formatted without regard to our formatting conventions, so I'm not going
> to ask that you adjust indention on this little hunk since it mirrors
> nearby code.

Ok, I adjusted the patch.

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: [email protected]
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Reply via email to