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?
>
> I think your change is missing a check somewhere. When I compile your
> test I initially get "target does not support atomic profile update,
> single mode is selected", but then it still does the atomic path.
> Before your patch is just used the non-atomic updates. So it appears
> something isn't quite right yet.
This was fixed by:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bd0d3ba672870be1dfd5b58ddd0dbb95b4f80c04
--
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/
