[LLVMdev] Is there any known bug related to NoDuplicate in LLVM/Clang 3.5

Brandon Lloyd brandonl at nvidia.com
Fri Feb 6 09:45:49 PST 2015


I’ve run into the same issue. Some of the optimizations (e.g. jump threading) will duplicate code. Once your barrier function has been inlined it loses the noduplicate attribute. Therefore you should not inline your barrier function until the problematic passes run. The noinline attribute on the barrier function can be useful for this. However, you should note that you can’t combine noduplicate and noinline in current Clang. One of two gets ignored (I don’t remember which). You have to combine them at the IR level.

Brandon

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lu Mitnick
Sent: Thursday, February 05, 2015 11:37 AM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] Is there any known bug related to NoDuplicate in LLVM/Clang 3.5

Hello all,

I am using LLVM/Clang 3.5 to build a C++ extension. Such C++ extension contains a special function named "barrier", which shouldn't be duplicated. So I add __attribute__((noduplicate)) on barrier declaration.

For some reasons, I also add AlwaysInlineAttr attribute on each function except main function. The generated LLVM IR what I expect is only a main function with many LLVM IRs.

However when I counts the number of barrier function call of the output LLVM IR, I found the number is more than I used in source code. I am wondering whether there is any known bug related to NoDuplicate in LLVM/Clang 3.5?

PS. To find out the problematic LLVM pass that may duplicate my barrier function call. I also used -print-after-all to dump the generated LLVM IR of each pass. But the main function is too huge and the called pass is too much therefore it is not feasible to debug in this way. Do you have any other debug tips to find out the problematic LLVM pass?

Any suggestion is welcomed.

Thanks,
Yi-Hong

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150206/d3218b8a/attachment.html>


More information about the llvm-dev mailing list