[PATCH] D74387: [SYCL] Defer __float128 type usage diagnostics

[Mariya Podchishchaeva via Phabricator via cfe-commits]

Fznamznon added a comment.

In D74387#2023200 <https://reviews.llvm.org/D74387#2023200>, @jdoerfert wrote:

> In D74387#1992682 <https://reviews.llvm.org/D74387#1992682>, @Fznamznon wrote:
>
> > Okay, seems like OpenMP needs unsupported types diagnosing as well. I'm trying to adapt this patch for OpenMP, but it doesn't work out of the box because it diagnoses memcpy like operations, so with the current patch the code like this will cause diagnostics:
> >
> >    struct T {
> >      char a;
> >      __float128 f;
> >      char c;
> >      T() : a(12), f(15) {}
> >   }
> >  
> >   #pragma omp declare target
> >   T a = T();
> >   #pragma omp end declare target
> >
> >
> > It happens because member initialization in the constructor is still usage of `f` field which is marked unavailable because of type. I'm not sure that it is possible to understand how the unavailable declaration is used in the place where diagnostic about usage of unavailable declaration is actually emitted, so I will probably need some other place/solution for it.
> >
> > @jdoerfert , could you please help to understand how the diagnostic should work for OpenMP cases? Or you probably have some spec/requirements for it?
> >  Understanding what exactly is needed will help with the implementation, I guess.
>
>
> I missed this update, sorry.
>
> I don't think we have a spec wording for this, it is up to the implementations.
>
> In the example, a diagnostic is actually fine (IMHO). You cannot assign 15 to the __float128 on the device. It doesn't work. The following code however should go through without diagnostic:
>
>   struct T {
>      char a;
>      __float128 f;
>      char c;
>      T() : a(12), c(15) {}
>   }
>
>
> and it should translate to
>
>   struct T {
>      char a;
>      alignas(host_float128_alignment) char[16] __unavailable_f;
>      char c;
>      T() : a(12), c(15) {}
>   }
>
>
> Do you have other questions or examples we should discuss?


I'm not sure that I've discovered all examples and problems, but I have a couple of ones. I started with adapting current implementation for OpenMP and right now I'm analyzing corresponding OpenMP test fails (i.e. `clang/test/OpenMP/nvptx_unsupported_type_messages.cpp` and `clang/test/OpenMP/nvptx_unsupported_type_codegen.cpp`). There are a lot of differences between the old approach and new one, which I'm working on. The new diagnostic triggers more errors than the old one, so I'd like to understand in which concrete cases we shouldn't emit diagnostic. For example you mentioned that memcopy-like operations should be ok in device code.
Right now the current implementation of the diagnostic also emits errors for sample like this:

  struct T {
    char a;
    __float128 f;
    char c;
  };
  
  #pragma omp declare target
  T a;
  T b = a; // The diagnostic is triggered here, because implicit copy constructor uses unavailable field
  #pragma omp end declare target

Should we emit errors in such case too?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74387/new/

https://reviews.llvm.org/D74387