eliminating code at link-time, using a CRT built with -flto

[Richard Biener]

On Mon, Jun 30, 2025 at 8:59 AM Iain Sandoe <iain@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
>
>