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

Dmitry Polukhin via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 25 07:09:54 PST 2015


DmitryPolukhin added a comment.

New patch uploaded.


================
Comment at: include/llvm-c/Core.h:1890
@@ +1889,3 @@
+ */
+LLVMValueRef LLVMAddIFunc(LLVMModuleRef M, LLVMTypeRef Ty,
+                          LLVMValueRef Resolver, const char *Name);
----------------
rafael wrote:
> I am not sure about adding a C api right away. Maybe wait a bit once the patch is in?
I added it just for completeness. I can remove it before commit if needed. I'm worry that it will be easy to forget if I remove it now.

================
Comment at: include/llvm/IR/GlobalIndirectSymbol.h:63
@@ +62,3 @@
+  }
+  GlobalObject *getBaseObject(const DataLayout &DL, APInt &Offset) {
+    return dyn_cast<GlobalObject>(
----------------
rafael wrote:
> Is this meaningful for ifunc?
> 
> IMHO it is a design mistake for GlobalAlias to take an arbitrary expression. If ifunc can take just a GlobalValue that would be nice.
> 
It makes sense to me.

================
Comment at: include/llvm/IR/Module.h:591
@@ +590,3 @@
+/// @name IFunc Iteration
+/// @{
+
----------------
rafael wrote:
> Is there real value in these @{}?
I don't see them in generated doxygen so it seems useless. I put them just to follow style of surrounding code. I'll remove them if there a consensus here.

================
Comment at: include/llvm/IR/Module.h:593
@@ +592,3 @@
+
+  ifunc_iterator       ifunc_begin()            { return IFuncList.begin(); }
+  const_ifunc_iterator ifunc_begin() const      { return IFuncList.begin(); }
----------------
rafael wrote:
> clang-format
Same here, such formatting is used in the whole file very consistent so I decided to follow local style. Please let me know if you really want to reformat only new block of code differently.

================
Comment at: lib/AsmParser/LLParser.cpp:719
@@ -710,3 +718,3 @@
 
-  if (Ty != PTy->getElementType())
+  if (IsAlias && Ty != PTy->getElementType())
     return Error(
----------------
rafael wrote:
> Any type restrictions when it is not an alias?
At least we could check that it is a function. Checking the function return type is trickier because  GCC allows any type even void same as for the parameters of the function.


http://reviews.llvm.org/D15525





More information about the llvm-commits mailing list