I've reported this at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69708.
Just to summarize:
1) If early inlining is forced then fre replaces the many references
to sq and ipa inlining is able to do its job.
2) If early inlining is disabled then ipa inlining only works for the
compound literal c
> I was saying that early inlining is not supposed to catch this case
> but IPA inlining.
> it shouldn't need to inline g early to end up inlining the calls to sq. IPA
> CP
> should clone g for the case of it calling sq and then inlining should
> just do its job.
Ok, I fully agree with that, for
no
non-inlining problem to address here, despite the different outcomes
for the static const and the compound literal cases, and you're just
pointing out a different, unrelated, issue.
Cheers
--
Carlos
On Fri, Feb 5, 2016 at 8:28 AM, Richard Biener
wrote:
> On Thu, Feb 4, 2016 at 9:10 PM, Carl
re is only one call site for the global f.call and
another one for the local/literal f.call, so the fre pass just lets
them be. This is innocuous from the fre point of view, but disables
further inlining as described above.
On Thu, Feb 4, 2016 at 3:05 PM, Carlos Pita wrote:
> PS: I framed t
is not happening, late inline will miss the
chance to inline the reference from the static const struct member.
On Thu, Feb 4, 2016 at 1:08 PM, Carlos Pita wrote:
> Hi all,
>
> I've been trying to understand some bizarre interaction between
> optimizing passes I've obse
Hi all,
I've been trying to understand some bizarre interaction between
optimizing passes I've observed while compiling a heavily nested
inlined numerical code of mine. I managed to reduce the issue down to
this simple code:
``` test.c
typedef struct F {
int (*call)(int);
} F;
static int g(F
