[cfe-dev] [RFC] Delayed target-specific diagnostic when compiling for the devices.
Alexey Bataev via cfe-dev
cfe-dev at lists.llvm.org
Thu Jan 17 09:32:28 PST 2019
Ok, I will try to reuse and generalize currently existing functionality
for the purposes of the OpenMP. Most probably, we won't need to add some
extra "walk-over-declarations" passes.
17.01.2019 12:27, John McCall пишет:
> On 17 Jan 2019, at 10:20, Finkel, Hal J. wrote:
>> On 1/17/19 4:01 AM, Alexey Bataev wrote:
>>> We cannot build the call graph during parsing. The function may be
>>> parsed already, but it may be called later.
>> Calling this "during parsing" maybe a bit over simplistic - it also
>> needs to deal with template instantiation, etc. However, the
>> parse-before-call is not a problem because all functions need to be
>> declared before being called, so we always have a way to record the
>> information (that seems to be the logic of the current approach).
> It probably makes more sense to walk functions retroactively looking for
> declaration references, but that's still quite feasible.
>>> I've come to an idea how to reuse the existing solution for Cuda for
>>> our purposes without the redesign and significant changes. Need some
>>> time to try to implement a prototype.
>>> Just one question though. Should I reuse the existing
>>> classes/objects for Cuda or better to add the specific ones for
>>> OpenMP, but almost with the same behavior? Or just rename the
>>> existing Cuda classes to be more common, like CudaDeferredDiags to
>>> something like DeviceDeferredDiags?
>> I definitely vote for renaming and generalizing the current
>> functionality unless there's some strong reason not to do so.
> I agree. If the functionality is generalized to apply to not just
> CUDA, it should be renamed to something non-CUDA-specific.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the cfe-dev