<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/112450>112450</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Reduce function size increase from inlined fixed point opertations
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            enhancement,
            llvm
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
            PiJoules
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          PiJoules
      </td>
    </tr>
</table>

<pre>
    On platforms that don't have target-specific lowering for fixed point intrinsics, the default lowering is to emit the appropriate shifts and arithmetic operations at each callsite (see https://github.com/llvm/llvm-project/blob/ddc3f2dd26c10b830d7137fc5f89049feec29033/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp#L10881 as an example). For baremetal devices that use fixed point as an alternative to soft floats (but also don't have native fixed point operations), this can lead to significant text increase since fixed point operations are expanded at each callisite. When using soft floats, operations like multiplication or division would just be a libcall. 

One way we can prevent this scaling per callsite is by deduping/outlining the actual fixed point operations. For example, a multiplication for a given fixed point type could also be a call to some function in the same TU which does that multiplication (ie. something akin to `__aeabi_fmul` but for each of the fixed point types). The compiler could emit this in the backend around target lowering and place it in a comdat section so we ensure one copy of it exists after linking. An alternative is we could add these symbols to llvm-libc and make these truly libcalls but for fixed point types. If this route is take, we'll need to flush out the details futher. This would be something enabled for `minsize/-Oz` builds.

A more difficult approach could be leveraging the outliner, but I'm not sure what stage in the pipeline the outliner runs.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyUVUGPGjkT_TXmUgpqTMPAgcN8ExHlU6SsdrPaY1RtV9OVcdstuwxDfv3KBjJMohz2AqhpV71X79UzpsQHT7RTq_8prf_g_4fsKCmt1er9DLMMIe5uT2ddsOfdZw-TQ-lDHBPIgAI2eKUfBAY8EgjGA8m7NJHhng24cKLI_gB9iNDzC1mYAnsB9hLZJzZJ6SeQgcBSj9nJ6xFOIAFoZKn_4zTFMEVGIUgD95IAvQWMLMNIwgbCRBGFg0-AAoRmAIPOJRYCpTeJCAaRKanlo9J7pfcHliF3cxNGpffOHW9f76YYvpERpfedC53Se2vNstfW6rVZNN1m2diHxfKhN6t-s23abU9k9LZZLu_qcDn3FCx9IK_0_i9yZAq4948flN5_qYP6dOU6N9Ok9PLTotlsFoCFGdALjpMjpbdz2IcIHUYaSdCBpSMbuo4_J3oz2MthdELRo3DRJEAKvUDvAkoqk-iyALoU3mp3ff2-2OtEld5ehOIEBj04Qlsr88EXpdELCL0UYU0kTASJvfldNcBIQC8Tekv2jVhc1JrDPwN5yKnY4A57QXBXxPEzwZid8OTY1IcQIlg-ciq_TyE7C99yEugIEBx3pcUcVPNeNY-Xz8-e4IRnOFHlNUU6UuFSiCaDrkCYKL46iRN0Z7Bk88T-oPQ-ZHHsy3vVpkYyut_wvij5Q9knwJ_xlz1BOPCR_Jsacp4ITCVUlauECqaLvCNBn331F7CvQBKOBF_-htPAZgAbbob5qaHSG6Z5LSFDIYHPpUAAtW6-fkXCjr_2Y3Zq3UDxTQFY1Qp9bfMzyFQN-2UoaMeJXRldhX1dZE43gB2aZ6obHLK31-h4Xf-y3JNDQ8DFVYVuGC0KpMseQQpFNPIpR4LgS8PpXGCxAL1wKgHRC0Vw7J_LksHj28XgVFW_DNXaAqr49jx2wdXsqVlQXFPBjPhM13ckZne--Sn9mMsvs5jDx_7COYZ88Y7gc1X-REo_OAeeqC5S73IaIGS5hqEguwR9loFimWcBW5F2dCcWeewc2dpdrZuxROp3Unr_7vP3i2LsbJrfG_4RxhAJLPc9mxK4NVjr_t3qOzpSxMPN0heDUyywC9WPSj-M4INAHf2puCoJHuim7MQTlRNvTkPMPs1ndre02-UWZ7RbPJTMbJtNOxt2m3bTrLoe2_WCrO1WzfKhoWW72ti2aRdrmvFON7pdNIuVXi7atp2vNqul7lvbd4vertu1ahsakd28yDYP8TDjlDLtFgvdrpqZw45cul515Af0hkbyUm47_aS0vgR3vfrirkrf5UNSbeOKl16rCouj3Z9ks7nbujL31_DrYxiBfSFuf8kCuYTBLEe3-88XUuWUlN5faR13-t8AAAD__2ZKuZA">