CC1352R: TI ARM CGT v20.2.7LTS 64-bit Comparison Problem with -O3

Hello,

I am writing code for a CC1352R1 running SDK version 4.40.04.04 with TI compiler
version 20.2.7 LTS, and have encountered a strange problem that occurs with
optimization level O3 or higher.

I have modified the Project Zero example from SDK 4.40.04.04 to reproduce the
issue: /cfs-file/__key/communityserver-discussions-components-files/538/optimization_5F00_problem_5F00_example.zip
In the attached archive, you will find that the following files have been
added to the Application folder:

• pb.h
• pb_common.h
• pb_common.c
• pb_encode.h
• pb_encode.c

(These files are from the nanopb library: https://github.com/nanopb/nanopb)

Aside from adding these files, project_zero.c has been modified to call
pb_encode_varint at the end of ProjectZero_init:

#include "pb.h"
#include "pb_encode.h"

pb_ostream_t stream = PB_OSTREAM_SIZING;
uint64_t value = 0x200b162d74e5;
if(pb_encode_varint(&stream, value))
{
    Log_info1("varint encoded size=%d", stream.bytes_written);
}

When run with optimization level 2, the program provides the expected output: varint encoded size=7
When run with optimization level 3, the program exhibits the problem: varint encoded size=1

Digging deeper, it appears that the value <= 0x7F comparison is not producing the expected result within pb_encode_varint:

bool checkreturn pb_encode_varint(pb_ostream_t *stream, pb_uint64_t value)
{
    if (value <= 0x7F)
    {
        /* Fast path: single byte */
        pb_byte_t byte = (pb_byte_t)value;
        return pb_write(stream, &byte, 1);
    }
    else
    {
#ifdef PB_WITHOUT_64BIT
        return pb_encode_varint_32(stream, value, 0);
#else
        return pb_encode_varint_32(stream, (uint32_t)value, (uint32_t)(value >> 32));
#endif
    }
}

When run with optimization level 2, pb_encode_varint chooses the else case and calls pb_encode_varint_32 as expected.
With optimization level 3, pb_encode_varint chooses the if case and calls pb_write, even though value == 0x200b162d74e5.

Looking at the disassembly, I can see a difference between O2 and O3, but I'm not sure where the problem lies.

O2:

O3:

Is this a known issue with the 20.2.7 compiler? I've looked through the known defects linked in the release notes, but didn't find anything that looks exactly like this: 20.2.7 Known Defects.

Can you suggest a workaround other than switching back to optimization level 2? The CC1352's flash is nearly full for our application, and optimization level 3 provides a significant reduction in binary size.

Thank you!
Peter