This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Improve printing and semantic check related to implicit addr space
AcceptedPublic

Authored by yaxunl on Oct 12 2017, 11:41 AM.

Details

Summary

There are two issues:

  1. only (void*)0 should be treated as nullptr
  1. only explicit addr space should be printed

This patch introduces a flag in Qualifier to indicating a non-default address space qualifier is deduced by context. Only
non-implicit address space qualifier will be print out when printing AST. It is also used to identify nullptr.

However this review does not rule out alternative approaches, e.g. using AttributedType. We will explore alternative approaches.

This patch depends on https://reviews.llvm.org/D35082

Diff Detail

Event Timeline

yaxunl created this revision.Oct 12 2017, 11:41 AM
yaxunl edited the summary of this revision. (Show Details)Oct 12 2017, 11:45 AM
Anastasia accepted this revision.Oct 13 2017, 8:48 AM

LGTM! Thanks!

Can we close https://bugs.llvm.org/show_bug.cgi?id=33418 after this commit?

test/SemaOpenCL/null_literal.cl
38

Does this extra cast test anything we already miss to test?

This revision is now accepted and ready to land.Oct 13 2017, 8:48 AM
yaxunl marked an inline comment as done.Oct 16 2017, 10:55 AM

LGTM! Thanks!

Can we close https://bugs.llvm.org/show_bug.cgi?id=33418 after this commit?

Will do.

test/SemaOpenCL/null_literal.cl
38

Yes. It tests a generic pointer of zero value can be explicitly casted to a global pointer. This should be true for any generic pointer, however since pointers with zero value have special handling, we want to make sure this still works.

rjmccall added inline comments.Oct 23 2017, 12:29 AM
include/clang/AST/Type.h
337

This is probably cleaner as:

Mask = (Value ? (Mask | ImplicitAddrSpaceMask) : (Mask & ~ImplicitAddrSpaceMask));
lib/AST/ASTContext.cpp
2290

It looks like your changes here are making implicitness part of the canonical type, which is wrong, because implicitly- and explicitly-qualified types are not actually different types.

That is fixable, but I'm going to ask you to investigate whether you can solve this problem with AttributedType before you introduce this complexity into the qualifier system.