[cfe-dev] [RFC] Delayed target-specific diagnostic when compiling for the devices.
Finkel, Hal J. via cfe-dev
cfe-dev at lists.llvm.org
Wed Jan 16 21:46:26 PST 2019
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?
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
More information about the cfe-dev
mailing list