This is an archive of the discontinued LLVM Phabricator instance.

[PR41008][OpenCL] Add OpenCL C compatibility mode to C++ for OpenCL
Needs ReviewPublic

Authored by kpet on Oct 3 2019, 6:18 AM.

Details

Summary

... and support the restrict keyword in that mode.

In this mode, compatibility with OpenCL C is favoured over
compatibility with C++. Intended uses include migrating
existing OpenCL C code and mixing OpenCL C and C++ for OpenCL
code.

Signed-off-by: Kevin Petit <kevin.petit@arm.com>

Diff Detail

Event Timeline

kpet created this revision.Oct 3 2019, 6:18 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 3 2019, 6:18 AM

Is there a test that shows that that keyword is still not provided for C++ after this?

kpet added a comment.EditedOct 3 2019, 8:18 AM

There doesn't seem to be a test for this (enabling restrict in C++ doesn't make any existing test fail). I couldn't find any test checking that OpenCL or C++/OpenCL keywords generally aren't enabled in C or C++. Doing this generically would essentially equate to writing unit tests for getKeywordStatus.

EDIT: I have verified that restrict is indeed rejected in C++.

Can you please explain why we are deviating from C++ on this? My concern is that this can potentially uncover bugs in C++ parsing due to un-handled restrict cases that would have to be fixed in some unclear way... I would appreciate more detailed analysis before we go ahead.

kpet added a comment.Oct 4 2019, 3:55 AM

Something I should probably have explained in the commit message is that the functionality provided by restrict is already present in C++, where it is already exposed using different keywords. If you look at clang/include/clang/Basic/TokenKinds.def, there are __restrict__ and __restrict aliases that end up producing tok::kw_restrict. The only thing this patch does is enabling the restrict keyword in C++ for OpenCL for compatibility with OpenCL C (see more on that on the bug). I don't expect any special handling will be required since the functionality is already supported both in C++ and OpenCL C.

kpet updated this revision to Diff 230620.Nov 22 2019, 2:38 AM
kpet retitled this revision from [PR41008][OpenCL] Support restrict keyword in C++ mode to [PR41008][OpenCL] Add OpenCL C compatibility mode to C++ for OpenCL.
kpet edited the summary of this revision. (Show Details)

As discussed offline, let's only enable restrict under a compatibility flag. PTAL.

I think we should use -fpermissive rather than adding similar flag to Clang. At the end we might end up with other cases where we need similar mechanism it doesn't make sense to add a flag for each case.

Also I am not sure that what you are doing here is really enabling OpenCL C compatibility mode that would imply to me that restrict is expected to behave in C++ mode as it was in C but is it really the case?

kpet added a comment.Nov 22 2019, 5:36 AM

Thanks for the feedback.

I think we should use -fpermissive rather than adding similar flag to Clang.

Could you point me at a use of -fpermissive for a similar case? Also it seems -fpermissive is not mentioned in the Clang manual or the help text. Am I missing something?

At the end we might end up with other cases where we need similar mechanism it doesn't make sense to add a flag for each case.

Completely agree and that was one of the reasons I decided to add a generic flag like this. I felt that compatibility with existing OpenCL C source was an important enough use-case to warrant adding a flag for it especially since, as you say, we expect such a flag could be useful to control several bits of behaviour.

Also I am not sure that what you are doing here is really enabling OpenCL C compatibility mode that would imply to me that restrict is expected to behave in C++ mode as it was in C but is it really the case?

Isn't restrict mainly an optimisation feature? That's certainly my reading of 6.7.3-7 in the C99 spec:

The intended use of the restrict qualifier (like the register storage class) is to promote
optimization, and deleting all instances of the qualifier from all preprocessing translation
units composing a conforming program does not change its meaning (i.e., observable
behavior).

The main goal here is to be able to consume existing OpenCL C source without modifications. I thought that enabling existing behaviour for restrict/__restrict that may result in additional optimisations was more useful than just discarding restrict, which would be a valid way of achieving compatibility. Is there something specific that worries you?

Thanks for the feedback.

I think we should use -fpermissive rather than adding similar flag to Clang.

Could you point me at a use of -fpermissive for a similar case? Also it seems -fpermissive is not mentioned in the Clang manual or the help text. Am I missing something?

bin/clang -fpermissive test.cl

Clang already has the flag added. So you can just start using it I presume. Feel free to document it.

At the end we might end up with other cases where we need similar mechanism it doesn't make sense to add a flag for each case.

Completely agree and that was one of the reasons I decided to add a generic flag like this. I felt that compatibility with existing OpenCL C source was an important enough use-case to warrant adding a flag for it especially since, as you say, we expect such a flag could be useful to control several bits of behaviour.

Also I am not sure that what you are doing here is really enabling OpenCL C compatibility mode that would imply to me that restrict is expected to behave in C++ mode as it was in C but is it really the case?

Isn't restrict mainly an optimisation feature? That's certainly my reading of 6.7.3-7 in the C99 spec:

The intended use of the restrict qualifier (like the register storage class) is to promote
optimization, and deleting all instances of the qualifier from all preprocessing translation
units composing a conforming program does not change its meaning (i.e., observable
behavior).

The main goal here is to be able to consume existing OpenCL C source without modifications. I thought that enabling existing behaviour for restrict/__restrict that may result in additional optimisations was more useful than just discarding restrict, which would be a valid way of achieving compatibility. Is there something specific that worries you?

C++ deviates from C so restrict in C++ might not be restrict in C. Can we confidently say we will support restrict exactly like OpenCL C does i.e. C99?

In other words I believe it is much safe to say that we support restrict in adhoc way that deviates C++ for OpenCL documentation without implying developers should refer to OpenCL C and C99 spec to get how it works. We can also use this mechanism for any behavior that deviates the documentation rather than adding a flag for each (i.e. we might want to deviate in something that doesn't come from OpenCL C at all).