[cfe-dev] suspecting a bug in Clang

[Christudasan D via cfe-dev]

Hi Akira,

I have applied this patch in my workspace to add the attributes to function
prototypes.
---------------------------------------------------------------------------------------------------------------------
--- basecode/cfe-3.5.0.src/lib/CodeGen/CodeGenModule.cpp
+++ myworkspace/cfe-3.5.0.src/lib/CodeGen/CodeGenModule.cpp
@@ -834,6 +834,10 @@
   if (!IsIncompleteFunction)
     SetLLVMFunctionAttributes(FD, getTypes().arrangeGlobalDeclaration(GD),
F);

+  // add target specific attributes to function declaration/prototype as
well
+  if (!FD->isDefined())
+         getTargetCodeGenInfo().SetTargetAttributes(FD, F, *this);
+
   // Add the Returned attribute for "this", except for iOS 5 and earlier
   // where substantial code, including the libstdc++ dylib, was compiled
with
   // GCC and does not actually return "this".
---------------------------------------------------------------------------------------------------------------------

This code comes in 'SetFunctionAttributes' which is common to both function
definition and declaration. (target attributes for all global definitions -
both functions and variables, are handled already at
'setNonAliasAttributes')

Thanks,
Christu

On Fri, Sep 9, 2016 at 10:30 AM, Akira Hatanaka <ahatanaka at apple.com> wrote:

>
> On Sep 7, 2016, at 9:08 PM, Christudasan D via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> All,
>
>
> I am facing a problem with LLVM 3.5 Compiler and suspect it is a bug in
> the clang. I earlier posted this query to llvm-dev list.
>
>
> Here is my observation.
>
>
> I am trying to support a target specific function attribute for a
> particular target machine.
>
> Having followed the steps specified in the compiler documentation, I see
> the attribute is passed to the backend if we include the attribute in the
> function definition. But this attribute is not propagate to the backend if
> I include it only in the function’s prototype/declaration (in the C
> program).
>
>
> This virtual function (given below) invocation in
> clang/lib/CodeGen/CodeGenModule.cpp in clang is responsible for attaching
> the target specific attributes to the backend CodeGen objects (functions,
> variables etc.)
>
> getTargetCodeGenInfo().SetTargetAttributes(D, GO, *this)
>
>
> I found that this virtual function is getting invoked only for function
> definitions and not for function declarations.
>
>
> Actual requirement:
>
> Along with regular C functions we have special functions supported in the
> target and its definition and invocation will always come in different
> compilation units. There must be a way to recognize these special functions
> at the call-sites during codegen in the backend. By attaching some info in
> the function prototype, we can recognize these special functions at the
> call-site during backend codegen. That’s why I thought of a new target
> specific attribute to achieve this purpose.
>
>
> *Is it really a bug?*
>
> When I compile a program having function declarations/prototypes with
> generic attributes like __attribute__((*const*)), clang will add it to
> that function’s attributelist in the IR and it will be available in the
> backend.
>
>
> Similarly I expected the target specific attribute should also be added to
> the attributelist available in the backend and I should be able to identify
> it using *F.hasFnAttribute("XYZ")*, where XYZ is the new attribute name.
>
> I understand that a look-up in the prototype for function-attrs is very
> rare at codegen. But I was keen to ask this when I found that the standard
> attributes (*'const',* for example) are actually propagated to the
> backend through function prototype.
>
> In the sample program below I have declared function *foo* with attribute
> '*const'* and you can see '*readnone'* is added to the attribute list.
>
> *Sample Program:*
>
> extern void __attribute__((const)) foo (int);
>
> int main ()
> {
> int  my_var = 45;
>
> foo(my_var);
> return 0;
> }
> -----------------------------------------------------------------
> *Generated IR:*
>
> ; Function Attrs: nounwind
> define i16 @main() #0 {
>   %1 = alloca i16, align 2
>   %my_var = alloca i16, align 2
>   store i16 0, i16* %1
>   call void @llvm.dbg.declare(metadata !{i16* %my_var}, metadata !13),
> !dbg !14
>   store i16 45, i16* %my_var, align 2, !dbg !15
>   %2 = load i16* %my_var, align 2, !dbg !16
>   call void @foo(i16 %2) #1, !dbg !16
>   ret i16 0, !dbg !17
> }
>
> ; Function Attrs: nounwind readnone
> declare void @llvm.dbg.declare(metadata, metadata) #1
>
> ; Function Attrs: nounwind *readnone*
> declare void @foo(i16) #2
> ------------------------------------------------------------
> --------------------------------------------------------
>
>
> I think you are right: SetTargetAttributes doesn’t get called for function
> declarations. GetOrCreateLLVMFunction is called to generate the LLVM IR for
> a function declaration, which  eventually calls ConstructAttributeList, in
> which readnone is added. If you want to add target attributes to function
> declarations, I believe you’ll have to somehow call SetTargetAttributes in
> ConstructAttributeList.
>
> Since I work with LLVM 3.5 code-base, I am not sure whether this issue (if
> it is really a bug) has already been fixed with recent compiler releases.
>
> Please write to me.
>
>
> Thanks,
>
> Christu
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160910/e9882fd8/attachment.html>