[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?
> 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
>>> 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
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
More information about the cfe-dev