> On Jan 29, 2026, at 11:44, Richard Biener <[email protected]> wrote:
> 
> 
> 
>> Am 29.01.2026 um 16:57 schrieb Qing Zhao <[email protected]>:
>> 
>> Our internal customer is asking for this feature.
>> 
>> They used icc currently, with icc, then can get inline list, prof_used list, 
>> etc. from the binary.
>> 
>> The old studio compiler also provided such feature, there was compiler 
>> commentary section in the binary to record
>> many of the important compiler transformations along with the line number 
>> information.
>> 
>> If there is any performance issue with the application, such information 
>> will be very useful. Especially for large applications.
> 
> The best bet is probably -fopt-info which I think can do alternate outputs, 
> eventually JSON.

I see that -fsave-optimization-record can dump the optimization info along with 
source line number
info into a SRCFILE.opt-record.json.gz
https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#index-fsave-optimization-record

But it was mentioned that this option is in experimental stage. 
Can I recommend this one to our customer now instead of 
-fopt-info-options=filename?

>  That’s not in the binary itself, of course, but you could place it there 
> with some linker script.

Yes, that’s right.

thanks.

Qing
> 
> Richard 
> 
>> Qing
>> 
>> 
>>> On Jan 29, 2026, at 05:30, Florian Weimer <[email protected]> wrote:
>>> 
>>> * Jakub Jelinek via Gcc:
>>> 
>>>> On Thu, Jan 29, 2026 at 09:49:40AM +0100, Richard Biener via Gcc wrote:
>>>>>> On Wed, Jan 28, 2026 at 4:43 PM Qing Zhao via Gcc <[email protected]> 
>>>>>> wrote:
>>>>>>> Does GCC provide any option to record optimization information, such as 
>>>>>>> inlining, loop transformation,
>>>>>>> profiling consistency, etc into specific sections of binary code?
>>>>>> 
>>>>>> No.
>>>> 
>>>> Well, inlining is recorded in debug info.  And I don't see what benefit
>>>> woiuld be to encode the rest, without source information like that is not
>>>> really useful and with source around you can always recompile and look for
>>>> compiler dumps or opt info, debug info provides details how a particular
>>>> TU has been compiled (with what options etc.).
>>> 
>>> It's hard to recompile in a generic fashion because build systems are so
>>> varied.  Depending on what people are trying to achieve, that's more of
>>> a theoretical option.
>>> 
>>> (Capturing source code so that it becomes available for recompilation
>>> would be interesting for many other applications, too.)
>>> 
>>> Thanks,
>>> Florian


Reply via email to