Hi, You should repost this to llvm-...@lists.llvm.org<mailto:llvm-...@lists.llvm.org>. This list is purely for auto generated bugzilla emails.
Cheers, James On 29 Aug 2016, at 14:19, Christudasan D via llvm-bugs <llvm-bugs@lists.llvm.org<mailto:llvm-bugs@lists.llvm.org>> wrote: Greetings to all. I am facing a problem with LLVM 3.5 and suspect it is a bug. 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. 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 _______________________________________________ llvm-bugs mailing list llvm-bugs@lists.llvm.org<mailto:llvm-bugs@lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
