----- Am 28. Dez 2025 um 14:26 schrieb Sebastian Huber [email protected]:
> ----- 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; Oh, it looks like I confused left and right. This should be an RSHIFT_EXPR: gassign *assign3 = gimple_build_assign (counter_high_64, RSHIFT_EXPR, 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/ -- 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/
