https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
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 optimized, but at the
same time inlining of functions calling always inline
function into an always inline function might introduce
cycles of edges to be always inlined in the callgraph.
We might want to be smarter and just avoid this type of inlining. */
|| (DECL_DISREGARD_INLINE_LIMITS (node->decl)
&& lookup_attribute ("always_inline",
DECL_ATTRIBUTES (node->decl))))
which I think is sensible but the issue is that for some reason the
skvx::Vec<4, unsigned int>::Vec (_1, s_6(D)) calls are not always_inline.
(gdb) p node->callees
$3 = <cgraph_edge* 0x7ffff301c068 (<cgraph_node * 0x7ffff2f43000 "__ct_base
"/8008> -> <cgraph_node * 0x7ffff3338dd0 "__ct_comp "/8006>)>
(gdb) p node->callees->next_callee
$4 = <cgraph_edge* 0x7ffff301c000 (<cgraph_node * 0x7ffff2f43000 "__ct_base
"/8008> -> <cgraph_node * 0x7ffff3338dd0 "__ct_comp "/8006>)>
__attribute__((always_inline))
void skvx::VecStorage<8, unsigned int>::VecStorage (struct VecStorage * const
this, unsigned int s)
{
struct Vec * _1;
struct Vec * _2;
<bb 2> :
*this_4(D) ={v} {CLOBBER};
_1 = &this_4(D)->lo;
skvx::Vec<4, unsigned int>::Vec (_1, s_6(D));
_2 = &this_4(D)->hi;
skvx::Vec<4, unsigned int>::Vec (_2, s_6(D));
return;
the location info points to
__attribute__((always_inline)) Vec(typename ConvertNative<N, T>::type
native) : Vec(bit_pun<Vec>(native)) {}
I'm not sure what fails to work here.
