https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|13.3|13.4
--- Comment #28 from Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #27 from Richard Biener ---
(In reply to Eric Gallager from comment #26)
> (In reply to Richard Biener from comment #20)
> > Unfortunately there isn't a knob to diagnose late inlined always-inline
> > functions.
>
> Is there a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
Richard Biener changed:
What|Removed |Added
Target Milestone|13.2|13.3
--- Comment #25 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #24 from rguenther at suse dot de ---
On Tue, 11 Jul 2023, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
>
> --- Comment #23 from Jan Hubicka ---
> But it would be nice to see why the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #23 from Jan Hubicka ---
But it would be nice to see why the functions are not early inlined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #22 from Jan Hubicka ---
I will cook up the patch to keep multiple variants of nodes pre-inline
and we will see how much that affects compile time & how hard it will be
to get unit size esitmates right.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #21 from Richard Biener ---
Created attachment 55512
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55512=edit
another testcase
This one needs -mavx2 -mf16c -mfma -fPIC -O2 -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #20 from Richard Biener ---
(In reply to Richard Biener from comment #19)
> It seems that the C++ FE change in comment#13 causes libreoffice to fail to
> build with
>
> [ 553s]
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #19 from Richard Biener ---
It seems that the C++ FE change in comment#13 causes libreoffice to fail to
build with
[ 553s]
/home/abuild/rpmbuild/BUILD/libreoffice-7.5.4.2/workdir/UnpackedTarball/skia/include/private/SkVx.h:
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #17 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:d88fd2e1d0720e6f892da9ff48e9a301a7ad0ad4
commit r14-2172-gd88fd2e1d0720e6f892da9ff48e9a301a7ad0ad4
Author: Jan Hubicka
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #16 from Jan Hubicka ---
> > We already have plenty of GF_CALL_ flags, so adding one should be easy?
>
> We have 3 bits left :/ I was hoping that cgraph_edge lives long
> enough? But I suppose we're not keeping them across the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #15 from rguenther at suse dot de ---
On Wed, 28 Jun 2023, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
>
> --- Comment #14 from Jan Hubicka ---
> >
> > why disallow caller->indirect_calls?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #14 from Jan Hubicka ---
>
> why disallow caller->indirect_calls?
See testcase in comment #9
>
> > + return false;
> > + for (cgraph_edge *e2 = callee->callees; e2; e2 = e2->next_callee)
>
> I don't think this flys -
>
> why disallow caller->indirect_calls?
See testcase in comment #9
>
> > + return false;
> > + for (cgraph_edge *e2 = callee->callees; e2; e2 = e2->next_callee)
>
> I don't think this flys - it looks quadratic. Can we compute this
> in the inline summary once instead?
I guess I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #13 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:abdf0b6cdff5783b97f35ad61ae31433f0569dfd
commit r14-2149-gabdf0b6cdff5783b97f35ad61ae31433f0569dfd
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #12 from rguenther at suse dot de ---
On Mon, 26 Jun 2023, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
>
> --- Comment #11 from Jan Hubicka ---
> Hi,
> what about this. It should make at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #11 from Jan Hubicka ---
Hi,
what about this. It should make at least quite basic inlining to happen
to always_inline. I do not think many critical always_inlines have
indirect calls in them. The test for lto is quite bad and I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #10 from rguenther at suse dot de ---
On Fri, 23 Jun 2023, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
>
> --- Comment #8 from Jan Hubicka ---
> > > I was playing with the idea of warning
Just so it is somewhere, here is a testcase that we can't inline leaf
functions to always_inlines unless we do some tracking of what calls
were formerly indirect calls.
We really overloaded always_inline from the original semantics "drop
inlining heuristics" into "be sure that result is inlined"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #9 from Jan Hubicka ---
Just so it is somewhere, here is a testcase that we can't inline leaf
functions to always_inlines unless we do some tracking of what calls
were formerly indirect calls.
We really overloaded always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #8 from Jan Hubicka ---
> > I was playing with the idea of warning when at lto time when comdats have
> > different command line options, but this triggers way too often in practice.
>
> Really? :/
Yep, for example firefox consist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #7 from Richard Biener ---
(In reply to Jan Hubicka from comment #6)
> Comdats are really in conflict with the fact that we have command line
> options. I blame C++ standard for that and I don't think there is fully
> satisfactory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #6 from Jan Hubicka ---
Comdats are really in conflict with the fact that we have command line options.
I blame C++ standard for that and I don't think there is fully satisfactory
solution to this problem.
I was playing with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #4 from Richard Biener ---
So we run into
/* Never inline regular functions into always-inline functions
during incremental inlining. This sucks as functions calling
always inline functions will get less
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #3 from Richard Biener ---
So it's actually that we require the instantiations but we are not able to
fully optimize avx::[rect_]memset* before LTO streaming. In fact we're not too
far from that:
void skvx::Vec<2, unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #2 from Richard Biener ---
The desired symbol table before LTO streaming has no symbols in the
skvx:: namespace
Just look at the final symbol table when not compiling with -flto, it takes
until the 'Optimized Symbol table' to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #1 from Richard Biener ---
Created attachment 55378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55378=edit
preprocessed testcase
This is one of the TUs in question, preprocessed with GCC 13. It was built
with -O3 -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Target
31 matches
Mail list logo
