> On Tue, May 22, 2018 at 9:21 AM, Jan Hubicka <hubi...@ucw.cz> wrote:
> >> >>>>> > class ipa_opt_pass_d;
> >> >>>>> > typedef ipa_opt_pass_d *ipa_opt_pass;
> >> >>>>> > @@ -2894,7 +2896,8 @@
> >> >>>>> > cgraph_node::only_called_directly_or_aliased_p (void)
> >> >>>>> > && !DECL_STATIC_CONSTRUCTOR (decl)
> >> >>>>> > && !DECL_STATIC_DESTRUCTOR (decl)
> >> >>>>> > && !used_from_object_file_p ()
> >> >>>>> > - && !externally_visible);
> >> >>>>> > + && !externally_visible
> >> >>>>> > + && !lookup_attribute ("ifunc", DECL_ATTRIBUTES (decl)));
> >> >>>>>
> >> >>>>> How's it handled for our own generated resolver functions? That is,
> >> >>>>> isn't there sth cheaper than doing a lookup_attribute here? I see
> >> >>>>> that make_dispatcher_decl nor ix86_get_function_versions_dispatcher
> >> >>>>> adds the 'ifunc' attribute (though they are TREE_PUBLIC there).
> >> >>>>
> >> >>>> Is there any drawback of setting force_output flag?
> >> >>>> Honza
> >> >>>
> >> >>> Setting force_output may prevent some optimizations. Can we add a bit
> >> >>> for IFUNC resolver?
> >> >>>
> >> >>
> >> >> Here is the patch to add ifunc_resolver to cgraph_node. Tested on x86-64
> >> >> and i686. Any comments?
> >> >>
> >> >
> >> > PING:
> >> >
> >> > https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00647.html
> >> >
> >>
> >> PING.
> > OK, but please extend the verifier that ifunc_resolver flag is equivalent to
> > lookup_attribute ("ifunc", DECL_ATTRIBUTES (decl))
> > so we are sure things stays in sync.
> >
>
> Like this
>
> diff --git a/gcc/symtab.c b/gcc/symtab.c
> index 80f6f910c3b..954920b6dff 100644
> --- a/gcc/symtab.c
> +++ b/gcc/symtab.c
> @@ -998,6 +998,13 @@ symtab_node::verify_base (void)
> error ("function symbol is not function");
> error_found = true;
> }
> + else if ((lookup_attribute ("ifunc", DECL_ATTRIBUTES (decl))
> + != NULL)
> + != dyn_cast <cgraph_node *> (this)->ifunc_resolver)
> + {
> + error ("inconsistent `ifunc' attribute");
> + error_found = true;
> + }
> }
> else if (is_a <varpool_node *> (this))
> {
>
>
> Thanks.
Yes, thanks!
Honza
>
> --
> H.J.
