This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Add declarations with enum/typedef args
ClosedPublic

Authored by svenvh on Feb 17 2021, 4:42 AM.

Details

Summary

Add the remaining missing builtin function declarations that have enum
or typedef argument or return types.

Diff Detail

Event Timeline

svenvh created this revision.Feb 17 2021, 4:42 AM
svenvh requested review of this revision.Feb 17 2021, 4:42 AM
Anastasia added inline comments.Feb 19 2021, 6:54 AM
clang/lib/Sema/OpenCLBuiltins.td
932

Btw, I am guessing you are matching the behavior of opencl-c.h, but however it doesn't seem entirely conformant.

cl_mem_fence_flags get_fence(gentype *ptr)

So I guess we should have implemented these as other functions from Table 22. Built-in Address Space Qualifier Functions in clang? But since the void pointer is only used as a parameter and not return value I doubt this is customer visible. Should we add a comment or something?

clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
185

Should work_group_barrier and fences also be added to the testing?

svenvh added inline comments.Feb 19 2021, 9:02 AM
clang/lib/Sema/OpenCLBuiltins.td
932

Yes, I'm matching opencl-c.h here, as the "gentype argument to indicate any of the built-in data types supported by OpenCL C or a user defined type. Since this cannot be captured" can't be expressed literally. I can add the following comment if that makes sense?

// The OpenCL 3.0 specification defines these with a "gentype" argument indicating any builtin
// type or user-defined type, which cannot be represented currently.  Hence we slightly diverge
// from this by providing only the following two overloads with a void pointer.
clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
185

MemFenceFlags are already tested using barrier() on line 23, so not strictly needed. I added this test to verify the combination of MemFenceFlags and extensions. Do you think we're missing any tablegen functionality coverage that would require adding more builtins to the test (also taking into account the comment on lines 10-13)?

Anastasia added inline comments.Feb 22 2021, 8:22 AM
clang/lib/Sema/OpenCLBuiltins.td
932

Yes, I think a comment is good enough. We could even create a spec bug because it is literally not possible to implement without a magic and just using void* is so easy and straight forward.

1106

I think this should be renamed now, but we can do as a separate change.

I would suggest using something like OverloadTypes instead...

clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
185

Taking into account the definition it's not easy to tell. I was trying to apply the strategy of any new group of declarations is to be tested but it might not be the original intention. I still think we do need to come up with some sort of unambiguous strategy but perhaps it is not in the scope of this patch.

svenvh updated this revision to Diff 325783.Feb 23 2021, 7:03 AM

Add comment about get_fence.

svenvh added inline comments.Feb 23 2021, 7:32 AM
clang/lib/Sema/OpenCLBuiltins.td
932

Added the comment.

1106

Agreed that renaming belongs to a separate patch, we can probably bikeshed over the actual name. TypeTuple would already be better than TypePair for this case. I find OverloadTypes a bit ambiguous (I guess with "Overload" you intend to refer to a particular instance of the overloaded function, but not sure if it's common to use "overload" as a noun). ReturnTypeAndArgumentTypes or OverloadedFunctionTypes seem more accurate but a bit unwieldy...

clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
185

any new group of declarations is to be tested but it might not be the original intention.

That has not been the convention for this test indeed. It's a bit hard to give an exact definition when the purpose of the test is to do a quick sweep across the main functional aspects of the -fdeclare-opencl-builtins machinery. As mentioned in various other reviews, a full test for all OpenCL builtins is desirable to have, but outside the scope of this test (which is probably more like a best-effort test).

Anastasia accepted this revision.Feb 23 2021, 7:46 AM

LGTM! Thanks!

clang/lib/Sema/OpenCLBuiltins.td
933

I would suggest changing this slightly to:

which cannot be represented currently -> which cannot be represented in C based languages

otherwise, it feels like there would be a way to represent it later. I just want to make sure it is clear that this is not a limitation of Tablegen or anything else in the implementation but rather conceptual issue.

1106

Yes, we can use more domain-specific names I would prefer those to TypeTuple.

This revision is now accepted and ready to land.Feb 23 2021, 7:46 AM
This revision was automatically updated to reflect the committed changes.