----- Am 4. Feb 2026 um 4:38 schrieb Sebastian Huber 
[email protected]:

> Hello Jeff,
> 
> ----- Am 29. Dez 2025 um 20:08 schrieb Jeffrey Law 
> [email protected]:
> 
>> On 12/28/2025 7:03 PM, Sebastian Huber wrote:
>>> I used this test case to double check that the shifting is now correct:
>>>
>>> int a(void);
>>> int b(void);
>>> int c(int);
>>> int f(int *i)
>>> {
>>>    if (c(i[0]) || c(i[1]) || c(i[2]) || c(i[3]) || c(i[4]) ||
>>>        c(i[5]) || c(i[6]) || c(i[7]) || c(i[8]) || c(i[9]) ||
>>>        c(i[10]) || c(i[11]) || c(i[12]) || c(i[13]) || c(i[14]) ||
>>>        c(i[15]) || c(i[16]) || c(i[17]) || c(i[18]) || c(i[19]) ||
>>>        c(i[20]) || c(i[21]) || c(i[22]) || c(i[23]) || c(i[24]) ||
>>>        c(i[25]) || c(i[26]) || c(i[27]) || c(i[28]) || c(i[29]) ||
>>>        c(i[30]) || c(i[31]) || c(i[32]) || c(i[33]) || c(i[34]) ||
>>>        c(i[35]) || c(i[36]) || c(i[37]) || c(i[38]) || c(i[39])) {
>>>      return a();
>>>    } else {
>>>      return b();
>>>    }
>>> }
>>>
>>> Interestingly, GCC now reuses the "amoor.w zero,zero" operations (see "j 
>>> .L46").
>> Right.  That's not a huge surprise to me.  If we look at the gimple we see:
>> 
>> 
>>> ;;   basic block 3, loop depth 0
>>> ;;    pred:       2
>>>   __atomic_fetch_or_4 (&__gcov8.f[0], 1, 0);
>>>   __atomic_fetch_or_4 (&MEM <long long int> [(void *)&__gcov8.f + 4B],
>>> 0, 0);
>>>   __atomic_fetch_or_4 (&__gcov8.f[1], 0, 0);
>>>   __atomic_fetch_or_4 (&MEM <long long int> [(void *)&__gcov8.f +
>>> 12B], 0, 0);
>>>   _8 = a (i_3(D)); [tail call]
>>>   goto <bb 5>; [100.00%]
>>> ;;    succ:       5
>>>
>>> ;;   basic block 4, loop depth 0
>>> ;;    pred:       2
>>>   __atomic_fetch_or_4 (&__gcov8.f[0], 0, 0);
>>>   __atomic_fetch_or_4 (&MEM <long long int> [(void *)&__gcov8.f + 4B],
>>> 0, 0);
>>>   __atomic_fetch_or_4 (&__gcov8.f[1], 1, 0);
>>>   __atomic_fetch_or_4 (&MEM <long long int> [(void *)&__gcov8.f +
>>> 12B], 0, 0);
>>>   _6 = b (0); [tail call]
>> So to improve the code you need to recognize the atomic_fetch_or_4 where
>> the object is IOR'd with the constant 0 as a nop and remove those
>> statements (or not emit them to begin with).  In general our optimizers
>> don't do a whole lot with atomics right now.
> 
> should I try to add these optimizations for a constant 0 to the patch or can 
> we
> do this in a follow up patch?
> 
> Is there a simple check to figure out if "tree counter" is a constant 0?

What doesn't work is this:

diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index a573725f253..8ae084db692 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -1047,14 +1047,20 @@ split_update_decision_counter (edge e, tree ref, tree 
counter, tree
     gsi_insert_after (&gsi, assign4, GSI_NEW_STMT);
 
     /* Atomically bitwise-or the low 32-bit counter parts */
-    gcall *call1 = gimple_build_call (atomic_ior_32, 3, addr_low,
-                                     counter_low_32, relaxed);
-    gsi_insert_after (&gsi, call1, GSI_NEW_STMT);
+    if (!integer_zerop (counter_low_32))
+       {
+           gcall *call1 = gimple_build_call (atomic_ior_32, 3, addr_low,
+                                             counter_low_32, relaxed);
+           gsi_insert_after (&gsi, call1, GSI_NEW_STMT);
+       }
 
     /* Atomically bitwise-or the high 32-bit counter parts */
-    gcall *call2 = gimple_build_call (atomic_ior_32, 3, addr_high,
-                                     counter_high_32, relaxed);
-    gsi_insert_after (&gsi, call2, GSI_NEW_STMT);
+    if (!integer_zerop (counter_high_32))
+       {
+           gcall *call2 = gimple_build_call (atomic_ior_32, 3, addr_high,
+                                             counter_high_32, relaxed);
+           gsi_insert_after (&gsi, call2, GSI_NEW_STMT);
+       }
 }
 
 /* Add instrumentation to a decision subgraph.  EXPR should be the
@@ -1203,6 +1209,9 @@ instrument_decisions (array_slice<basic_block> expr, 
size_t condno,
            /* _global_true |= _true, _global_false |= _false  */
            for (size_t k = 0; k != 2; ++k)
            {
+               if (integer_zerop (next[k]))
+                   continue;
+
                tree ref = tree_coverage_counter_ref (GCOV_COUNTER_CONDS,
                                                      2*condno + k);
                if (use_atomic_builtin)

-- 
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