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

[Tom Stellard]

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