[PATCH] Adding support for NoDuplicate function attribute in CLang
Richard Smith
richard at metafoo.co.uk
Wed Nov 20 16:01:25 PST 2013
If this is supported by LLVM for all platforms, I don't see a good reason
to restrict it to just OpenCL. Any hardware might have a barrier
instruction, and if it does, we'd want the noduplicate behavior there.
On Wed, Nov 20, 2013 at 3:06 PM, Marcello Maggioni <marcello at codeplay.com>wrote:
> Hmm, I don't feel confortable in commenting on this, because I don't have
> enough background myself on why the attribute has been added to LLVM. I
> know about the OpenCL use case just because I'm specifically working on
> that and the need for the NoDuplicate attribute popped out, but I'm not
> aware of possible usages of the same in the pure C/C++ world.
>
> I could immagine some hardware specific use scenario where in an embedded
> system using built-ins exercising some hardware features that have a
> similar functionality of a barrier (a synchronization primitive of some
> sort) this could be useful, but nothing else.
>
> Cheers,
> Marcello
>
>
> On 20/11/13 20:11, Aaron Ballman wrote:
>
>> On Wed, Nov 20, 2013 at 2:25 PM, Marcello Maggioni
>> <marcello at codeplay.com> wrote:
>>
>>> Sorry, I missed the mail.
>>>
>>> Hmm, well, ideally if the call through the pointer is duplicated ,and the
>>> function call shouldn't be duplicated (like in some implementations of
>>> "barrier()" in OpenCL) the result might be wrong (in the case of a
>>> barrier
>>> the result is a dead-lock).
>>> Of course, OpenCL itself doesn't have this problem because it doesn't
>>> have
>>> function pointers ...
>>>
>> Which brings me to my round-about question -- should this be exposed
>> as an OpenCL-only attribute in the same way we do with CUDA
>> attributes? Eg) only expose a GNU spelling for it, and check in Sema
>> whether lang options are for OpenCL and warn if not compiling for
>> OpenCL.
>>
>> It sounds like this is intended for OpenCL users and it will have
>> little utility to non-OpenCL users (feel free to correct me if I'm
>> wrong on this account).
>>
>> ~Aaron
>>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131120/c9cec00e/attachment.html>
More information about the cfe-commits
mailing list