Hi, sorry for bumping this again I forgot to mention that Windows inlining, from what I remember, was ok before gcc 14 landed. It seemed that only once gcc 14 came about that the insane inlining started happening. This might point to the inlining heuristics having changed, but unfortunately gcc 13 no longer works on my Windows device for some reason, so checking to make sure that the difference is between compiler versions is out of the question. Regardless, thanks for the pointers on what options to use to view gcc inlining details! I'll get back to you if I find anything substantial.
best regards, Julian On Tue, Apr 1, 2025 at 3:12 PM Richard Biener <richard.guent...@gmail.com> wrote: > > On Mon, Mar 31, 2025 at 9:15 PM Eric Botcazou <botca...@adacore.com> wrote: > > > > > You can see what -fuse-linker-plugin says, what gcc/auto-host.h contains > > > for HAVE_LTO_PLUGIN. I don't know whether the BFD linker (or mold) > > > supports linker plugins on windows. I do know that libiberty > > > simple-object > > > does not support PE, that is, at _least_ (DWARF) debuginfo will be subpar. > > > > Here's an excerpt of a LTO compilation with -Wl,--verbose=2 on native > > Windows: > > > > C:/GNATPRO/25.1/bin/../lib/gcc/x86_64-w64-mingw32/13.3.1/../../../../x86_64- > > w64-mingw32/bin/ld.exe: C:\tmp\ccCnskmU.o (symbol from plugin): symbol `fma' > > OK, so I infer from '(symbol from plugin)' that linker plugin support is there > and enabled by default. That should rule out inlining differences > from that end. > There is of course still the thing that PE and ELF have different > visibility rules > and handling of what is COMDAT in ELF, dependent on the programming language > (C vs. C++) this would be also expected to produce different inlining. > > More details can always be gathered from comparing -fopt-info-inline or in > even more detail from looking at the -fdump-ipa-inline[-details] dump (both > from WPA stage, so make sure to specify those options at link time). > > Richard. > > > definition: DEF, visibility: DEFAULT, resolution: PREVAILING_DEF_IRONLY > > C:/GNATPRO/25.1/bin/../lib/gcc/x86_64-w64-mingw32/13.3.1/../../../../x86_64- > > w64-mingw32/bin/ld.exe: C:\tmp\ccCnskmU.o (symbol from plugin): symbol > > `main' > > definition: DEF, visibility: DEFAULT, resolution: PREVAILING_DEF > > C:/GNATPRO/25.1/bin/../lib/gcc/x86_64-w64-mingw32/13.3.1/../../../../x86_64- > > w64-mingw32/bin/ld.exe: C:\tmp\ccCnskmU.o (symbol from plugin): symbol > > `__fpclassify' definition: UNDEF, visibility: DEFAULT, resolution: > > RESOLVED_EXEC > > attempt to open C:\tmp\ccbENa6D.ltrans0.ltrans.o succeeded > > C:\tmp\ccbENa6D.ltrans0.ltrans.o > > > > This is with GNU ld. > > > > -- > > Eric Botcazou > > > >
