[PATCH] D15525: [GCC] Attribute ifunc support in llvm

Duncan P. N. Exon Smith via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 11 13:00:45 PST 2016


> On 2016-Jan-06, at 07:38, Dmitry Polukhin <dmitry.polukhin at gmail.com> wrote:
> 
> DmitryPolukhin added a comment.
> 
> Friendly ping, please review this patch.
> 
> Clang part of ifunc support was approved for commit but llvm part needs to be committed first.
> 
> 
> http://reviews.llvm.org/D15525
> 
> 
> 

> Index: lib/Transforms/IPO/GlobalDCE.cpp
> ===================================================================
> --- lib/Transforms/IPO/GlobalDCE.cpp
> +++ lib/Transforms/IPO/GlobalDCE.cpp
> @@ -205,9 +205,9 @@
>      // referenced by the initializer to the alive set.
>      if (GV->hasInitializer())
>        MarkUsedGlobalsAsNeeded(GV->getInitializer());
> -  } else if (GlobalAlias *GA = dyn_cast<GlobalAlias>(G)) {
> -    // The target of a global alias is needed.
> -    MarkUsedGlobalsAsNeeded(GA->getAliasee());
> +  } else if (GlobalIndirectSymbol *GIS = dyn_cast<GlobalIndirectSymbol>(G)) {
> +    // The target of a global alias or ifunc is needed.
> +    MarkUsedGlobalsAsNeeded(GIS->getIndirectSymbol());

It seems like this change could be done more incrementally.  For
example, if you add `GlobalIndirectSymbol` in an initial commit, you can
then convert all the appropriate things from `GlobalAlias` to
`GlobalIndirectSymbol` one at a time, before finally landing the new
`GlobalIFunc` commit which adds the new IR type.

(I'm just picking on the first such change in the patch.)

>    } else {
>      // Otherwise this must be a function object.  We have to scan the body of
>      // the function looking for constants and global values which are used as
> Index: lib/IR/AsmWriter.cpp
> ===================================================================
> --- lib/IR/AsmWriter.cpp
> +++ lib/IR/AsmWriter.cpp
> @@ -249,11 +254,15 @@
>      predictValueUseListOrder(&F, nullptr, OM, Stack);
>    for (const GlobalAlias &A : M->aliases())
>      predictValueUseListOrder(&A, nullptr, OM, Stack);
> +  for (const GlobalIFunc &I : M->ifuncs())
> +    predictValueUseListOrder(&I, nullptr, OM, Stack);
>    for (const GlobalVariable &G : M->globals())
>      if (G.hasInitializer())
>        predictValueUseListOrder(G.getInitializer(), nullptr, OM, Stack);
>    for (const GlobalAlias &A : M->aliases())
>      predictValueUseListOrder(A.getAliasee(), nullptr, OM, Stack);
> +  for (const GlobalIFunc &I : M->ifuncs())
> +    predictValueUseListOrder(I.getResolver(), nullptr, OM, Stack);

Can you add a lit test (if there isn't one already) that calls
verify-uselistorder in a way that would confirm this "predict" call was
added in the right place?

I think it should be sufficient to a GIF that's referenced by each of
GlobalVariable, GlobalAlias, GlobalIFunc, and Function; and a Function
that's referenced in the same four ways.

>    for (const Function &F : *M)
>      for (const Use &U : F.operands())
>        predictValueUseListOrder(U.get(), nullptr, OM, Stack);
> Index: docs/LangRef.rst
> ===================================================================
> --- docs/LangRef.rst
> +++ docs/LangRef.rst
> @@ -760,6 +760,25 @@
>  * No global value in the expression can be a declaration, since that
>    would require a relocation, which is not possible.
>  
> +.. _langref_ifunc:
> +
> +IFuncs
> +-------
> +
> +IFuncs, like as aliases, don't create any new data or func. They are just a new
> +symbol that dynamic linker resolves at runtime by calling a resolver function.
> +
> +IFuncs have a name and a resolver that is a function called by dynamic linker
> +that returns address of another function associated with the name.
> +
> +Aliases may have an optional :ref:`linkage type <linkage>` and an optional

s/Aliase/IFunc/

> +:ref:`visibility style <visibility>`.
> +
> +Syntax::
> +
> +    @<Name> = [Linkage] [Visibility] ifunc <IFuncTy>, <ResolverTy>* @<Resolver>
> +
> +
>  .. _langref_comdats:
>  
>  Comdats
> 



More information about the llvm-commits mailing list