arnavsharma990 opened a new pull request, #21214:
URL: https://github.com/apache/nuttx/pull/21214

   
<html><head></head><body><h2><span><span>Summary</span></span></h2><p><span><span>The
 constant 64-bit division optimization in 
</span></span><code><span><span>include/nuttx/lib/math32.h</span></span></code><span><span>
 is effectively disabled because 
</span></span><code><span><span>div64_const</span></span></code><span><span> is 
guarded by 
</span></span><code><span><span>CONFIG_HAVE_EXPRESSION_STATEMENT</span></span></code><span><span>,
 a symbol that is never defined in NuttX or 
nuttx-apps.</span></span></p><p><span><span>The guard has remained ineffective 
since the optimization was introduced in commit 
</span></span><code><span><span>7fc03e0084</span></span></code><span><span>. 
Commit </span></span><code><span><span>c32b683</span></span></code><span><span> 
later removed the 
</span></span><code><span><span>CONFIG_HAVE_LONG_LONG</span></span></code><span><span>
 condition, leaving the guard dependent entirely on the undefined 
symbol.</span></span></p><p><span><span>As a result, affe
 cted 64-bit division call sites fall back to ordinary 
</span></span><code><span><span>/</span></span></code><span><span> operations. 
On 32-bit targets, this can introduce expensive software division helpers 
instead of using the intended Granlund–Montgomery reciprocal 
multiplication.</span></span></p><p><span><span>This PR replaces the dead guard 
with a compiler capability check:</span></span></p><pre><code><span><span>#if 
!defined(__ghs__) &amp;&amp; (defined(__GNUC__) || 
defined(__clang__))</span></span></code></pre><p><span><span>This follows the 
existing compiler conventions in 
</span></span><code><span><span>include/nuttx/compiler.h</span></span></code><span><span>
 and enables the optimization for GCC and Clang while excluding Green Hills, 
which does not support statement expressions in all required 
contexts.</span></span></p><p><strong><span><span>Affected call 
sites:</span></span></strong></p><ul><li><p><code><span><span>include/nuttx/clock.h</span></span></code><span><span>
  — clock conversion functions and 
macros.</span></span></p></li><li><p><code><span><span>sched/wdog/wd_start.c:369</span></span></code><span><span>
 — watchdog 
timing.</span></span></p></li><li><p><code><span><span>include/nuttx/timers/oneshot.h:366</span></span></code><span><span>
 — oneshot timer 
calculations.</span></span></p></li><li><p><code><span><span>include/nuttx/timers/clkcnt.h:183,224,317,321</span></span></code><span><span>
 — clock counter conversions.</span></span></p></li></ul><p><span><span>The 
separate 
</span></span><code><span><span>lib_ultoa_invert.c</span></span></code><span><span>
 optimization is not included in this change. It requires additional 
modifications to 
</span></span><code><span><span>div64_const32</span></span></code><span><span> 
and will be considered separately.</span></span></p><p><span><span>Related 
issue: 
#21213</span></span></p><h2><span><span>Impact</span></span></h2><ul><li><p><strong><span><span>Binary
 size:</span></span></strong><span>
 <span> Reduced by 104 bytes in the tested 
</span></span><code><span><span>stm32f4discovery</span></span></code><span><span>
 minimal build (28,212 → 28,108 
bytes).</span></span></p></li><li><p><strong><span><span>Build 
system:</span></span></strong><span><span> No Kconfig or build-system 
changes.</span></span></p></li><li><p><strong><span><span>Hardware:</span></span></strong><span><span>
 No hardware-specific 
changes.</span></span></p></li><li><p><strong><span><span>Documentation:</span></span></strong><span><span>
 No changes 
required.</span></span></p></li><li><p><strong><span><span>Security:</span></span></strong><span><span>
 No security 
implications.</span></span></p></li><li><p><strong><span><span>Compatibility:</span></span></strong><span><span>
 The optimized path preserves the original integer division semantics. 
Unsupported compilers retain the existing 
fallback.</span></span></p></li><li><p><strong><span><span>Compiler 
support:</span></span></strong><span><span> Enabled for
  GCC and Clang; Green Hills is explicitly 
excluded.</span></span></p></li></ul><p><span><span>The remaining 
</span></span><code><span><span>_udivmoddi4</span></span></code><span><span> 
helper (816 bytes in the tested image) comes from 
</span></span><code><span><span>lib_ultoa_invert</span></span></code><span><span>
 and is outside the scope of this 
PR.</span></span></p><h2><span><span>Testing</span></span></h2><p><strong><span><span>Environment:</span></span></strong><span><span>
 macOS, Apple Clang 21.0.0 and 
</span></span><code><span>arm-none-eabi-gcc</span></code><span><span> 
16.2.0.</span></span></p><p><strong><span><span>Target:</span></span></strong><span><span>
 
</span></span><code><span><span>stm32f4discovery</span></span></code><span><span>
 (ARM Cortex-M4, 
32-bit).</span></span></p><p><strong><span><span>Configuration:</span></span></strong><span><span>
 Minimal 
</span></span><code><span><span>stm32f4discovery:nsh</span></span></code><span><span>
 build with </span></span><code>
 
<span><span>CONFIG_INIT_ENTRYPOINT="hello_main"</span></span></code><span><span>
 and unnecessary features disabled.</span></span></p><h3><span>1. Baseline 
build</span></h3><pre><code><span><span>$ arm-none-eabi-size nuttx
      </span>text    data     bss     dec     hex
   <span>  28212     </span>800    2136   31148    79ac<span>
   
   $ grep -o "udivmoddi4\|aeabi_ldivmod\|aeabi_uldivmod" nuttx.map | sort | 
uniq -c
      1 aeabi_ldivmod
     20 aeabi_uldivmod
     20 udivmoddi4</span></span></code></pre><p><span><span>Disassembly of 
</span></span><code><span><span>clock_systime_timespec</span></span></code><span><span>
 confirmed the software division 
call:</span></span></p><pre><code><span><span>8001c56: f003 fd65  bl  8005724 
&lt;__aeabi_ldivmod&gt;</span></span></code></pre><h3><span>2. Modified 
build</span></h3><p><span>After replacing the guard with the compiler 
capability check:</span></p><pre><code><span><span>$ arm-none-eabi-size nuttx
      </span>text    data     bss     dec     hex
   <span>  28108     </span>800    2136   31044    7944<span>
   
   $ grep -o "udivmoddi4\|aeabi_ldivmod\|aeabi_uldivmod" nuttx.map | sort | 
uniq -c
     20 aeabi_uldivmod
     20 udivmoddi4</span></span></code></pre><p><span>Disassembly showed the 
division-helper call replaced by <span>hardware 
multiply-accumulate:</span></span></p><pre><code><span><span>8001c58: fbe0 2305 
 umlal  r2, r3, r0, r5</span></span></code></pre><h3><span><span>3. Build 
result</span></span></h3><pre><code><span>EXIT=0</span></code></pre><p><span>The
 build completed successfully without errors or warnings related to 
</span><code><span>math32.h</span></code><span>.</span></p><h3><span>4. Clang 
verification</span></h3><p><span>A minimal reproduction <span>of the 
statement-expression macro </span>compiled and ran successfully with Apple 
Clang 21.0.0:</span></p><pre><code><span>clang -std=gnu11 -Wall -Wextra 
test_math32.c -o test_math32
   
./test_math32</span></code></pre><p><span>Output:</span></p><pre><code><span>12345678</span></code></pre><p><span>A
 full Clang cross-target build was not performed<span> because 
</span></span><code><span><span>arm-none-eabi-clang</span></span></code><span><span>
 was unavailable.</span></span></p><h3><span><span>5. Binary size 
comparison</span></span></h3>
     | Text | Data | BSS
   -- | -- | -- | --
   Baseline | 28,212 | 800 | 2,136
   Modified | 28,108 | 800 | 2,136
   Difference | −104 | 0 | 0
   
   <p><span><span>The 
</span></span><code><span><span>_udivmoddi4</span></span></code><span><span> 
and 
</span></span><code><span><span>__aeabi_uldivmod</span></span></code><span><span>
 references remain in the image and are outside the scope of this 
change.</span></span></p></body></html>


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to