From: Miod Vallat <miod@online.fr>
Subject: Re: cc seems to optimize out com_read_reg
To: Geoff Steckel <gwes@oat.com>
Cc: tech <tech@openbsd.org>
Date: Mon, 10 Nov 2025 08:54:17 +0000

> Working from OPENBSD_7_8
> Attaching acpi uart UAR1 from an AMD Ryzen 5 CPU
> BIOS ASROCK B550 PHantom Gaming 4 / American Megatrends rev 0x50011
> Highly cut down - full dmesg, etc on request
> I -think- this occurs for all amd64
> 
> in dev/ic/com.c line 1603 com_fifo_probe line 34 (+ or -)
> this: (release version 1.180)
>         for (len = 0; len < 256; len++) {
>                 timo = 2000;
>                 while (!ISSET(com_read_reg(sc, com_lsr),
>                     LSR_RXRDY) && --timo)
>                         delay(1);
>                 if (!timo || com_read_reg(sc, com_data) != (len + 1))
>                         break;
>         }
> results bad len = 0
> 
> this: (test)
>         uint8_t c = 0x5A;
>         for (len = 0; len < 256; len++) {
>                 timo = 2000;
>                 while (!ISSET(com_read_reg(sc, com_lsr),
>                     LSR_RXRDY) && --timo)
>                         delay(1);
>                 if (!timo || (c = com_read_reg(sc, com_data)) != (len + 1))
>                         break;
>         }
>         printf("fifo probe stopped at %d with %02x\n", len, c);
> results good len = 16
> 
> It looks like cc is optimizing out the com_read_reg(sc, com_data)
> unless the value is used later.

I'd say the compiler decides that, since com_read_reg returns a uint8_t
value, and the value of `len + 1` can be up to 256, which doesn't fit in
8 bits, it can aggressively optimize the comparison away as never
possibly satisfied.

If you change the uppor limit in the for() loop from 256 to 255 in the
original code, does it work any better?