On Mon, Jun 30, 2025 at 8:59 AM Iain Sandoe <i...@sandoe.co.uk> wrote:
>
> Hi
>
> I am investigating the following;
>
> in the program code I have calls like
>
> uint16_t x = __crt_func ( 10 );
>
> where the argument is guaranteed to be a compile-time uint16_t literal.
>
> So I’ve arranged a series of crts (built with -flto) where one is like
>
> 1/
>
> uint16_t
> __crt_func (const uint16_t in) { return in; }
>
> and others are like
>
> 2/
> uint16_t
> __crt_func (const uint16_t in) { return 5; }
>
> ====
>
> The objective is for an LTO build to eliminate code that becomes dead when
> the crt returns the various constants.
>
> So, case (2) works fine - the calls get eliminated and the resulting dead
> code too.
>
> However, case (1) is not doing what I expect.
>
> When I look at the ltrans0.ltrans.272.optimized, the __crt_func () body is
> there (so it can see it) but still one call to the crt is made and then the
> value from that call is used, instead of figuring out that this can all be
> const-propagated &c.
>
> I’ve declared the crt
> uint16_t __crt_func (uint16_t) __attribute__((__const__));
That shouldn't be necessary.
> So…
> am I making a mistake
> in expectation?
This ("guaranteed optimization"). But I'd say it's a bug in IPA CP
cost modeling,
I suggest to look at the WPA stage -fdump-ipa-cp-details and
-fdump-ipa-inline-details
dumps to figure why we decide it's not worth optimizing.
> in how the crt is declared?
>
> any other insights?
>
> thanks
> Iain
>
>
