On 12/28/2025 6:26 AM, Sebastian Huber wrote:
----- 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;
So I went into the tree checking code and we do indeed have looser
checks for the shift/rotate cases; essentially we allow the shift/rotate
count to be any integral type or vector of integrals. So we're OK with
a constant node like you're using.
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.
That was my conclusion as well.
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.
No worries at all. I'm not familiar with the gcov code, so we're both
just kind of slogging through it.
So the assignment above will just convert the types and as I think
through it, the type of the shift isn't going to matter because you
shift the upper 32 bits into the low 32 bit positions. The upper 32
bits will be copies of the original sign bit. But then we use the
nop-conversion to drop those upper 32 bits anyway. So it shouldn't
really matter if they were zeros or copies of the sign bit because we
never use them.
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.
Thanks. I'll take another looksie, but we're probably good to go after
working through this stuff a bit on this thread.
jeff