This is the mail archive of the
mailing list for the GCC project.
Re: What would it take to always force indirect inlining?
- From: Martin Jambor <mjambor at suse dot cz>
- To: Daniel Santos <daniel dot santos at pobox dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>
- Date: Tue, 22 Jul 2014 22:44:14 +0200
- Subject: Re: What would it take to always force indirect inlining?
- Authentication-results: sourceware.org; auth=none
- References: <53C80753 dot 2020703 at pobox dot com> <20140718095440 dot GB29223 at virgil dot suse> <53C9841B dot 7040903 at pobox dot com>
On Fri, Jul 18, 2014 at 03:31:23PM -0500, Daniel Santos wrote:
> On 07/18/2014 04:55 AM, Martin Jambor wrote:
> >On Thu, Jul 17, 2014 at 12:26:43PM -0500, Daniel Santos wrote:
> >>I've recently discovered that a function marked always_inline but
> >>called by pointer won't always be inlined. What would it take to
> >>assure that this either always happens or generates an error?
> >Generally, that is the case. Direct non-inlined calls of
> >always_inline functions thus indicate that the destination become
> >known only after inlining in the optimization pipeline. Without more
> >context, especially without knowing how exactly you call my_quicksort
> >function, it is impossible to say why. If you cannot povide us with
> >the source code (I would be interested if you can), you can try
> >compiling with -fdump-tree-all -fdump-ipa-all-details and go through
> >the generated dump files to find out at what point it becomes known.
> >ipa-cp and ipa-inline dumps also contain information about what
> >inlining context of your function.
> Hello. I've given it a new home:
> https://github.com/daniel-santos/cmeta. I'm using cmake for the
> first time and I'm not sure that I like it. For now, you have to
> *manually* specify your CFLAGS. This is what I'm using:
> CFLAGS="-std=gnu11 -march=native -g3 -pipe -Wall -Wextra
> -Wcast-align -Wno-unused-parameter -O2 -DNDEBUG"
> My -march=native is a Phenom 9850 and I did this on gcc 4.8.3. I
> have 4.9.0 installed, but I haven't examined that one just yet, but
> I will shortly. Also please note that this is currently not the
> worlds prettiest code! (sorry, I guess I'm vain)
I have had a look and it indeed seems to reveal that we miss an
important opportunity for indirect inlining and will work to fix it,
hopefully in the next major version of gcc. Meanwhile, if you want to
continue your experiments with current releases, you can replace your
ror function pointer with a macro (or its expansion, this is just an
illustration) like in the patch below and I believe it will just work,
at least on 4.9 (I have tried myself with trunk only).
If you want to continue discuss this path more, please take it off the
gcc development mailing list (you can also ask at gcc-help but I am
not subscribed there).
Thank you for the testcase,