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

[Alexey Bataev via cfe-dev]

It should be compilable for the device only iff function foo is not used
on the device.

-------------
Best regards,
Alexey Bataev

17.01.2019 10:24, Finkel, Hal J. пишет:
> 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
>>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190117/ac05769d/attachment.sig>