Lu Mitnick
2015-Feb-05 18:37 UTC
[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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150206/a6750bc1/attachment.html>
Matt Arsenault
2015-Feb-05 19:22 UTC
[LLVMdev] Is there any known bug related to NoDuplicate in LLVM/Clang 3.5
On 02/05/2015 10:37 AM, Lu Mitnick wrote:> 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 > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdevYou should be able to write a script that bugpoint can help reduce for you. Write a lit test that checks for the repeated calls to barrier and figure out the incantation necessary to get bugpoint to run with it -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150205/c182e59e/attachment.html>
Brandon Lloyd
2015-Feb-06 17:45 UTC
[LLVMdev] Is there any known bug related to NoDuplicate in LLVM/Clang 3.5
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>
Tom Stellard
2015-Feb-06 18:14 UTC
[LLVMdev] Is there any known bug related to NoDuplicate in LLVM/Clang 3.5
On Fri, Feb 06, 2015 at 05:45:49PM +0000, Brandon Lloyd wrote:> 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. >Hi, For libclc we use a barrier intrinsic with the noinline attribute. This way you don't have to worry about it being inlined an losing the attribute. https://github.com/llvm-mirror/libclc/blob/master/r600/lib/synchronization/barrier_impl.ll -Tom> 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. > -----------------------------------------------------------------------------------> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev