This is an archive of the discontinued LLVM Phabricator instance.

Permit OpenCL event_t's to be constructed from integer value 0.
AbandonedPublic

Authored by sheredom on Feb 21 2014, 9:39 AM.

Details

Reviewers
rsmith
Summary

The OpenCL specification and conformance tests have code similar to;

void func(event_t e);
...
func((event_t)0);

Clang (in OpenCL language mode) currently supports the above, but without the explicit cast, like;

func(0);

But doesn't allow the explicit cast. This patch fixes this, and also adds in a more descriptive error for when a user does;

(event_t)5;

and also adds in some more expected results to the OpenCL event_t tests.

Any comments or suggestions would be greatly appreciated!

Diff Detail

Event Timeline

Also, ran check-all tests, results as below;

Neils-MacBook-Air:build neil$ ninja check-all
[1/1] Running all regression tests
lit.py: lit.cfg:196: note: using clang: '/Users/neil/repo/llvm/build/./bin/clang'
lit.py: lit.cfg:440: note: using SDKROOT: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk'
-- Testing: 16740 tests, 4 threads --
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Testing Time: 403.83s
  Expected Passes    : 16501
  Expected Failures  : 74
  Unsupported Tests  : 165

Can you show me where in the OpenCL spec this language rule is described? I can't find any allowance for casting zero to event_t.

include/clang/Basic/DiagnosticSemaKinds.td
6788

err_, not error_.

6789

Maybe '%1' instead of 'event_t' here, so we get a better diagnostic if the target type is a typedef ("cannot cast non-zero value '1' to 'foo' (aka 'event_t')")?

lib/Sema/SemaCast.cpp
2241

Capital F in For.

2242

Remove redundant parens around OpenCL check.

2243

Should be IntValue

2244

EvaluateAsInt is inappropriate here. I'm not sure exactly what the language rule is, but this surely isn't it. Maybe take a look at TryOCLZeroEventInitialization in SemaInit.cpp.

2244–2245

Space between if and (.

2245

We don't do the constant-on-the-left thing in the Clang codebase. Also, operator! is more efficient than != 0 for APSInt.

2251

Both arms of this if/else return, factor that out?

Thanks for the comments!

Its very obscure in the spec, but if you look at the functions that use event_t types, like async_work_group_copy it says 'The event argument can also be used to associate the async_work_group_copy with a previous async copy allowing an event to be shared by multiple async copies; otherwise event should be zero'.

We already allow passing 0 in such cases. I don't see any provision for allowing explicit casts from 0 to event_t. The "Explicit Casts" section says nothing about it, for instance.

I've seen behaviour similar to this being accepted by implementations, but you are correct in that the specification doesn't explicitly say that it is acceptable behaviour!

I've posted in the OpenCL forums here Clarification-on-event_t-usage-in-OpenCL-specification to see if I can get some clarification.

Thanks again for your help!

sheredom abandoned this revision.Feb 24 2014, 2:12 PM

Rejected my own review as specification is unclear on expected behaviour, will seek clarification on spec, then re-evaluate any intended patch.