On Fri, Apr 13, 2018 at 04:33:40PM +0200, Martin Liška wrote:
> > Ah, but we emit the resolver only if we see a use of it. That sounds quite
> > broken, resolver in each TU that uses it? Better to have one at each
> > definition...
> >
> > Jakub
> >
>
> So after quite some time I would need some brainstorming as I'm not sure how
> to
> fix that properly. Let's start how 'target' attribute works and I believe it
> should
> behave same as target_clones attribute:
I think the target_clones behavior if you put the <function>.resolver into
.text.<function> section in <function> comdat rather than
.text.<function>.resolver and <function>.resolver comdat is reasonable.
The thing is that both the <function>.resolver and <function> symbols are
defined in the section in which the resolver is defined.
Maybe it would be nice if the resolver was made not exported out of the TU,
and eventually, not necessarily now for GCC8, turn the specializations into
non-exported symbols too and put them into the same section or different
sections of the same comdat group.
For ctors and dtors we need extra care about the aliases, not sure if we can
have an alias to ifunc symbol, or if we need to emit two ifunc symbols with
the same resolver or what exactly.
And yes, it would be nice if the target attribute multiversioning worked
similarly to this. It would change behavior for it in ABI incompatible way,
the question is how much work it would be as well.
What you can do right now with the target attribute multiversioning and
couldn't do after the change would be e.g.
mv.h:
__attribute__((target ("default"))) void foo ();
__attribute__((target ("avx"))) void foo ();
mv1.C:
#include "mv.h"
__attribute__((target ("default"))) void foo () {}
mv2.C:
#include "mv.h"
__attribute__((target ("avx"))) void foo () {}
mv3.C:
#include "mv.h"
void bar () { foo (); }
You couldn't this in the semantics closer to target_clones, all the
definitions would need to be done in the same file which is where you'd also
get the ifunc symbol.
IMHO it is worth changing the semantics anyway, because the current one
isn't very well thought out, it doesn't really work well with comdats, can
have too many resolvers with the associated costs, etc.
Honza, do you agree?
Jakub
