public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Navid Rahimi <navidrahimi@microsoft.com>
To: Edgar Mobile <heideggm@hotmail.com>,
	"gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Subject: Re: Try to understand output of -fdump-ipa-inline
Date: Wed, 20 Jul 2022 19:35:29 +0000	[thread overview]
Message-ID: <CY4PR21MB154096289ACBF37D2D29DA06A38E9@CY4PR21MB1540.namprd21.prod.outlook.com> (raw)
In-Reply-To: <DM8PR16MB4357C813172AD7362285FAEDC78E9@DM8PR16MB4357.namprd16.prod.outlook.com>

> I tried to create a *.so example from it for which I literally copied the calling and called function. It is inlined correctly.
No, this would not work. What I meant is to try to comment out extra code as much as possible. Somewhere you are going to see a difference between (a) having a code and (b) elimination of the code. That would give a better insight into what is going on. Although admittedly this might not work either, or in some cases the code is too complex to do something like this. But That's what I would do at least.

Regarding the plt, I am not expert in this area. So take this with grain of salt. But my understanding is the PLT decision is happening inside the linker (or at least lower level IR inside GCC). So I would investigate why the inliner in GIMPLE IR layer does not inline the function. That would be much more relevant I suspect.

As I said, try the always_inline attribute and look at the result. Inliner does calculate a complex logic to decide whether it should inline a function or not. Your code is closed source, and it is not possible for me to evaluate it. It might be the case that the function is so big that the inliner decides that it worth not inlining at all.

Best wishes,
Navid.

________________________________________
From: Edgar Mobile <heideggm@hotmail.com>
Sent: Wednesday, July 20, 2022 01:10
To: Navid Rahimi; gcc-help@gcc.gnu.org
Subject: [EXTERNAL] Re: Try to understand output of -fdump-ipa-inline

I tried to create a *.so example from it for which I literally copied the calling and called function. It is inlined correctly.

In the original project, g++ seems to be determined to create a plt entry for the to-be-inlined function although I gave it the visibility=hidden attribute (also -fvisibility=hidden in the g++ parameters).

Will a plt entry prevent a function from being inlined?
Is there a way to find out why g++ creates a plt entry although I'm trying to prevent this?

Regards

________________________________
From: Navid Rahimi <navidrahimi@microsoft.com>
Sent: Tuesday, July 19, 2022 6:27 PM
To: gcc-help@gcc.gnu.org <gcc-help@gcc.gnu.org>; Edgar Mobile <heideggm@hotmail.com>
Subject: Re: Try to understand output of -fdump-ipa-inline

Have you tried to make a similar example? What I do in this situation is try to replicate exact situation but in a smaller case.

Inlining decision happens in multiple levels. It is hard to find out what is the exact reason this way.

Just as experiment, try it with always_inline [1] too.

1. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FCommon-Function-Attributes.html&data=05%7C01%7Cnavidrahimi%40microsoft.com%7Ce141bab94ee44bb350f008da6a2761e8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637939014628304353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SiR0dysewI0uQmlAcj2wGBOh7djERmaue%2BCfPZbXQA4%3D&reserved=0>



Best wishes,
Navid.

________________________________________
From: Gcc-help <gcc-help-bounces+navidrahimi=microsoft.com@gcc.gnu.org> on behalf of Edgar Mobile via Gcc-help <gcc-help@gcc.gnu.org>
Sent: Tuesday, July 19, 2022 06:56
To: gcc-help@gcc.gnu.org
Subject: [EXTERNAL] Try to understand output of -fdump-ipa-inline

Greetings,

I try to find out why a function (inline keyword, defined in header) is not inlined. Example for -fdump-ipa-inline output:

Considering void Vertex::update(const Data&)/5927 with 40 size
 to be inlined into void SomeClass::updatePoly(const Data&, Polyline&)/11181 in /somepath/SomeClass.cpp:663
 Estimated badness is -0.000083, frequency 4.69.

The function is never inlined. unfortunately, the code is proprietary, so I cannot post everything.

Can anyone explain me the message above to find out why?
Thanks

      reply	other threads:[~2022-07-20 19:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-19 13:56 Edgar Mobile
2022-07-19 18:27 ` Navid Rahimi
2022-07-20  8:10   ` Edgar Mobile
2022-07-20 19:35     ` Navid Rahimi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CY4PR21MB154096289ACBF37D2D29DA06A38E9@CY4PR21MB1540.namprd21.prod.outlook.com \
    --to=navidrahimi@microsoft.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=heideggm@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).