[cfe-dev] [RFC] Delayed target-specific diagnostic when compiling for the devices.

[Finkel, Hal J. via cfe-dev]

On 1/17/19 4:05 AM, Alexey Bataev wrote:
>
> Best regards,
> Alexey Bataev
>
>> 17 янв. 2019 г., в 0:46, Finkel, Hal J. <hfinkel at anl.gov> написал(а):
>>
>>
>>> On 1/16/19 8:45 AM, Alexey Bataev wrote:
>>>
>>> Yes, I thought about this. But we need to delay the diagnostic until
>>> the Codegen phase. What I need is the way to associate the diagnostic
>>> with the function so that this diagnostic is available in CodeGen.
>>>
>>> Also, we need to postpone the diagnotics not only for functions,
>>> but,for example, for some types. For example, __float128 type is not
>>> supported by CUDA. We can get error messages when we ran into
>>> something like `typedef __float128 SomeOtherType` (say, in some system
>>> header files) and get the error diagnostic when we compile for the
>>> device. Though, actually, this type is not used in the device code,
>>> the diagnostic is still emitted and we need to delay too and emit it
>>> only iff the type is used in the device code.
>>>
>> This should be fixed for CUDA too, right?
>>
>> Also, we still get to have pointers to aggregates containing those types
>> on the device, right?
>>
> No, why? This is not allowed and should be diagnosed too. If somebody tries somehow to use not allowed type for the device variables/functions - it should be diagnosed.


Because this should be allowed. If I have:

struct X {
  int a;
  __float128 b;
};

and we have some function which does this:

X *foo(X *x) {
  return x;
}

We'll certainly want this function to compile for all targets, even if
there's no __float128 support on some accelerator. The whole model only
really makes sense if the accelerator shares the aggregate-layout rules
of the host, and this is a needless hassle for users if this causes an
error (especially in a unified-memory environment where configuration
data structures, etc. are shared between devices).

Thanks again,

Hal


>
>> Thanks again,
>>
>> Hal
>>
>>
>>> -------------
>>> Best regards,
>>> Alexey Bataev
>>> 15.01.2019 17:33, John McCall пишет:
>>>>> On 15 Jan 2019, at 17:20, Alexey Bataev wrote:
>>>>> This is not only for asm, we need to delay all target-specific
>>>>> diagnostics.
>>>>> I'm not saying that we need to move the host diagnostic, only the
>>>>> diagnostic for the device compilation.
>>>>> As for Cuda, it is a little but different. In Cuda the programmer
>>>>> must explicitly mark the device functions,  while in OpenMP it must
>>>>> be done implicitly. Thus, we cannot reuse the solution used for Cuda.
>>>> All it means is that you can't just use the solution used for CUDA
>>>> "off the shelf".  The basic idea of associating diagnostics with the
>>>> current function and then emitting those diagnostics later when you
>>>> realize that you have to emit that function is still completely
>>>> applicable.
>>>>
>>>> John.
>> -- 
>> Hal Finkel
>> Lead, Compiler Technology and Programming Languages
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory