* [Bug tree-optimization/54965] [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining
2012-10-18 1:50 [Bug tree-optimization/54965] New: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining siarhei.siamashka at gmail dot com
@ 2012-10-18 1:56 ` siarhei.siamashka at gmail dot com
2012-10-18 9:52 ` [Bug tree-optimization/54965] [4.6 Regression] " rguenth at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: siarhei.siamashka at gmail dot com @ 2012-10-18 1:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
--- Comment #1 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> 2012-10-18 01:56:34 UTC ---
Created attachment 28476
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28476
pixman-combine-float.i.gz - the original full preprocessed source
Applying the changes from
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=526b36a8a249c8c8698ca48ffeb8bff552f5a6fd
to 'passes.c' in GCC 4.6 branch "fixes" the reduced testcase. But pixman still
can't be compiled successfully, so also attaching the original full
preprocessed source.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining
2012-10-18 1:50 [Bug tree-optimization/54965] New: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining siarhei.siamashka at gmail dot com
2012-10-18 1:56 ` [Bug tree-optimization/54965] " siarhei.siamashka at gmail dot com
@ 2012-10-18 9:52 ` rguenth at gcc dot gnu.org
2012-10-18 10:48 ` siarhei.siamashka at gmail dot com
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-10-18 9:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-10-18
CC| |hubicka at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Known to work| |4.5.4, 4.7.2
Target Milestone|--- |4.6.4
Summary|[4.6] sorry, unimplemented: |[4.6 Regression] sorry,
|inlining failed in call to |unimplemented: inlining
|'foo': function not |failed in call to 'foo':
|considered for inlining |function not considered for
| |inlining
Ever Confirmed|0 |1
Known to fail| |4.6.4
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-18 09:52:27 UTC ---
void combine_conjoint_xor_ca_float ()
{
combine_channel_t j = pd_combine_conjoint_xor, k = pd_combine_conjoint_xor;
a[0] = k (0, b, 0, a[0]);
a[0] = k (0, b, 0, a[0]);
a[0] = k (0, b, 0, a[0]);
a[0] = j (0, c[0], 0, a[0]);
a[0] = k (0, c[0], 0, a[0]);
a[0] = k (0, c[0], 0, a[0]);
a[0] = k (0, c[0], 0, a[0]);
you are using indirect function calls here, GCC in 4.6 is not smart enough
to transform them to direct calls before inlining. Inlining of
always-inline indirect function calls is not going to work reliably.
Don't use always-inline or don't use indirect function calls to always-inline
functions. It makes always-inline function calls survive until IPA inlining
where we seem to honor limits even though we say we should disregard them.
Honza?
Considering pd_combine_conjoint_xor with 383 size
to be inlined into combine_conjoint_xor_ca_float in t.i:53
Estimated growth after inlined into all callees is +748 insns.
Estimated badness is -2147483648, frequency 1.00.
Processing frequency pd_combine_conjoint_xor
Called by combine_conjoint_xor_ca_float that is normal or hot
Inlined into combine_conjoint_xor_ca_float which now has time 1402 and size
2342,net change of +374.
Considering pd_combine_conjoint_xor with 383 size
to be inlined into combine_conjoint_xor_ca_float in t.i:54
Estimated growth after inlined into all callees is +374 insns.
Estimated badness is -2147483648, frequency 1.00.
Not inlining into combine_conjoint_xor_ca_float:--param large-function-growth
limit reached.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining
2012-10-18 1:50 [Bug tree-optimization/54965] New: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining siarhei.siamashka at gmail dot com
2012-10-18 1:56 ` [Bug tree-optimization/54965] " siarhei.siamashka at gmail dot com
2012-10-18 9:52 ` [Bug tree-optimization/54965] [4.6 Regression] " rguenth at gcc dot gnu.org
@ 2012-10-18 10:48 ` siarhei.siamashka at gmail dot com
2012-10-18 10:59 ` rguenther at suse dot de
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: siarhei.siamashka at gmail dot com @ 2012-10-18 10:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
--- Comment #3 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> 2012-10-18 10:47:51 UTC ---
(In reply to comment #2)
> void combine_conjoint_xor_ca_float ()
> {
> combine_channel_t j = pd_combine_conjoint_xor, k = pd_combine_conjoint_xor;
> a[0] = k (0, b, 0, a[0]);
> a[0] = k (0, b, 0, a[0]);
> a[0] = k (0, b, 0, a[0]);
> a[0] = j (0, c[0], 0, a[0]);
> a[0] = k (0, c[0], 0, a[0]);
> a[0] = k (0, c[0], 0, a[0]);
> a[0] = k (0, c[0], 0, a[0]);
>
> you are using indirect function calls here, GCC in 4.6 is not smart enough
> to transform them to direct calls before inlining. Inlining of
> always-inline indirect function calls is not going to work reliably.
Does this only apply to GCC 4.6?
> Don't use always-inline or don't use indirect function calls to always-inline
> functions.
This looks like it might be really inconvenient. Pixman relies on this
functionality in a number of places by doing something like this:
void always_inline per_pixel_operation_a(...)
{
...
}
void always_inline per_pixel_operation_b(...)
{
...
}
void always_inline big_function_template(..., per_pixel_operation_ptr foo)
{
...
/* do some calls to foo() in an inner loop */
...
}
void big_function_a(...)
{
big_function_template(..., per_pixel_operation_a);
}
void big_function_b(...)
{
big_function_template(..., per_pixel_operation_b);
}
Needless to say that we want to be absolutely sure that per-pixel operations
are always inlined. Otherwise the performance gets really bad if the compiler
ever makes a bad inlining decision.
The same functionality can be probably achieved by replacing always_inline
functions with macros. But the code becomes less readable, more error prone and
somewhat more difficult to maintain.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining
2012-10-18 1:50 [Bug tree-optimization/54965] New: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining siarhei.siamashka at gmail dot com
` (2 preceding siblings ...)
2012-10-18 10:48 ` siarhei.siamashka at gmail dot com
@ 2012-10-18 10:59 ` rguenther at suse dot de
2012-10-19 0:17 ` siarhei.siamashka at gmail dot com
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenther at suse dot de @ 2012-10-18 10:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> 2012-10-18 10:58:56 UTC ---
On Thu, 18 Oct 2012, siarhei.siamashka at gmail dot com wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
>
> --- Comment #3 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> 2012-10-18 10:47:51 UTC ---
> (In reply to comment #2)
> > void combine_conjoint_xor_ca_float ()
> > {
> > combine_channel_t j = pd_combine_conjoint_xor, k = pd_combine_conjoint_xor;
> > a[0] = k (0, b, 0, a[0]);
> > a[0] = k (0, b, 0, a[0]);
> > a[0] = k (0, b, 0, a[0]);
> > a[0] = j (0, c[0], 0, a[0]);
> > a[0] = k (0, c[0], 0, a[0]);
> > a[0] = k (0, c[0], 0, a[0]);
> > a[0] = k (0, c[0], 0, a[0]);
> >
> > you are using indirect function calls here, GCC in 4.6 is not smart enough
> > to transform them to direct calls before inlining. Inlining of
> > always-inline indirect function calls is not going to work reliably.
>
> Does this only apply to GCC 4.6?
No, that applies in general. If GCC isn't able to figure out which
function is called it cannot make sure always-inline functions are
always inlined. always-inline is an attribute that should be used
if it is incorrect to not inline, not if that's just good for
optimziation.
> > Don't use always-inline or don't use indirect function calls to always-inline
> > functions.
>
> This looks like it might be really inconvenient. Pixman relies on this
> functionality in a number of places by doing something like this:
>
> void always_inline per_pixel_operation_a(...)
> {
> ...
> }
>
> void always_inline per_pixel_operation_b(...)
> {
> ...
> }
>
> void always_inline big_function_template(..., per_pixel_operation_ptr foo)
> {
> ...
> /* do some calls to foo() in an inner loop */
> ...
> }
>
> void big_function_a(...)
> {
> big_function_template(..., per_pixel_operation_a);
> }
>
> void big_function_b(...)
> {
> big_function_template(..., per_pixel_operation_b);
> }
>
> Needless to say that we want to be absolutely sure that per-pixel operations
> are always inlined. Otherwise the performance gets really bad if the compiler
> ever makes a bad inlining decision.
>
> The same functionality can be probably achieved by replacing always_inline
> functions with macros. But the code becomes less readable, more error prone and
> somewhat more difficult to maintain.
In the above case you probably want big_function_a to have all
calls inlined. You can then conveniently use the flatten attribute:
void __attribute__((flatten)) big_function_b (...)
{
big_function_template(..., per_pixel_operation_b);
}
GCC will then inline all calls in that function but not ICE
when it fails to inline one case for some weird reason.
Richard.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining
2012-10-18 1:50 [Bug tree-optimization/54965] New: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining siarhei.siamashka at gmail dot com
` (3 preceding siblings ...)
2012-10-18 10:59 ` rguenther at suse dot de
@ 2012-10-19 0:17 ` siarhei.siamashka at gmail dot com
2012-10-19 8:36 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: siarhei.siamashka at gmail dot com @ 2012-10-19 0:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
--- Comment #5 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> 2012-10-19 00:17:13 UTC ---
(In reply to comment #4)
> In the above case you probably want big_function_a to have all
> calls inlined. You can then conveniently use the flatten attribute:
>
> void __attribute__((flatten)) big_function_b (...)
> {
> big_function_template(..., per_pixel_operation_b);
> }
>
> GCC will then inline all calls in that function but not ICE
> when it fails to inline one case for some weird reason.
That's nice, but "flatten" attribute does not seem to be widely supported by
the compilers. For example, clang-3.1 does not support it yet and the
enhancement request is still open since 2010 -
http://llvm.org/bugs/show_bug.cgi?id=7559
As far as I know, a few different compilers are currently in real use for
building pixman for various systems: GCC, Clang, Solaris Studio and MSVC. All
of them have some sort of "always_inline" attribute support, which makes it
more universal than "flatten".
> Don't use always-inline or don't use indirect function calls to
> always-inline functions. It makes always-inline function calls
> survive until IPA inlining where we seem to honor limits even
> though we say we should disregard them.
Is it too intrusive to fix GCC so that it would disregard limits in this case?
Or maybe introduce one more attribute which would be a strong inlining hint,
but still not cause compilation failure if some function can't be really
inlined?
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining
2012-10-18 1:50 [Bug tree-optimization/54965] New: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining siarhei.siamashka at gmail dot com
` (4 preceding siblings ...)
2012-10-19 0:17 ` siarhei.siamashka at gmail dot com
@ 2012-10-19 8:36 ` rguenth at gcc dot gnu.org
2012-10-23 14:03 ` hubicka at ucw dot cz
2013-04-12 16:18 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-10-19 8:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-19 08:36:06 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > In the above case you probably want big_function_a to have all
> > calls inlined. You can then conveniently use the flatten attribute:
> >
> > void __attribute__((flatten)) big_function_b (...)
> > {
> > big_function_template(..., per_pixel_operation_b);
> > }
> >
> > GCC will then inline all calls in that function but not ICE
> > when it fails to inline one case for some weird reason.
>
> That's nice, but "flatten" attribute does not seem to be widely supported by
> the compilers. For example, clang-3.1 does not support it yet and the
> enhancement request is still open since 2010 -
> http://llvm.org/bugs/show_bug.cgi?id=7559
>
> As far as I know, a few different compilers are currently in real use for
> building pixman for various systems: GCC, Clang, Solaris Studio and MSVC. All
> of them have some sort of "always_inline" attribute support, which makes it
> more universal than "flatten".
>
> > Don't use always-inline or don't use indirect function calls to
> > always-inline functions. It makes always-inline function calls
> > survive until IPA inlining where we seem to honor limits even
> > though we say we should disregard them.
>
> Is it too intrusive to fix GCC so that it would disregard limits in this case?
> Or maybe introduce one more attribute which would be a strong inlining hint,
> but still not cause compilation failure if some function can't be really
> inlined?
I think the particular case is a bug in GCC, I was just mentioning that
using indirect function calls to always-inline functions is always prone
to this kind of error.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining
2012-10-18 1:50 [Bug tree-optimization/54965] New: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining siarhei.siamashka at gmail dot com
` (5 preceding siblings ...)
2012-10-19 8:36 ` rguenth at gcc dot gnu.org
@ 2012-10-23 14:03 ` hubicka at ucw dot cz
2013-04-12 16:18 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: hubicka at ucw dot cz @ 2012-10-23 14:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
--- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> 2012-10-23 14:03:06 UTC ---
> you are using indirect function calls here, GCC in 4.6 is not smart enough
> to transform them to direct calls before inlining. Inlining of
> always-inline indirect function calls is not going to work reliably.
>
> Don't use always-inline or don't use indirect function calls to always-inline
> functions. It makes always-inline function calls survive until IPA inlining
> where we seem to honor limits even though we say we should disregard them.
Yes, we do. It was actually your change to move always_inline function handling
out of the small functions inlining into inline_always_inline_functions. The
motivation was that when done as part of small function inlining other inlining
may close cycles in the callgraph making always_inline inlining impossible.
In the presence of indirect calls, I do not think it is possible to honnor
always_inline completely because of the ordering issue.
Honza
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining
2012-10-18 1:50 [Bug tree-optimization/54965] New: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining siarhei.siamashka at gmail dot com
` (6 preceding siblings ...)
2012-10-23 14:03 ` hubicka at ucw dot cz
@ 2013-04-12 16:18 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-04-12 16:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Target Milestone|4.6.4 |4.7.0
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 16:18:03 UTC ---
The 4.6 branch has been closed, fixed in GCC 4.7.0.
^ permalink raw reply [flat|nested] 9+ messages in thread