[cfe-dev] [RFC] Delayed target-specific diagnostic when compiling for the devices.
Reid Kleckner via cfe-dev
cfe-dev at lists.llvm.org
Tue Jan 15 14:07:34 PST 2019
Didn't we already go through this for CUDA? It has all the same issues. I
see some comments about Sema::CUDADeferredDiags. I would look at that and
try to generalize it.
On Tue, Jan 15, 2019 at 1:58 PM John McCall via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On 14 Jan 2019, at 23:23, Finkel, Hal J. via cfe-dev wrote:
> > On 1/14/19 6:22 PM, Alexey Bataev wrote:
> >> Yes, it is implemented in the frontend. No, it is not implemented in
> >> the Sema analysis, it is implemented in Codegen part of the frontend.
> >> And it is almost impossible to implement it in Sema. It requires
> >> recursive analysis of the functions used (not only called directly,
> >> but also indirectly). The better place to implement it is the CodeGen
> >> of the frontend.
> > Your proposal makes sense to me. And, I agree, just moving the logic
> > to
> > CodeGen seems like the most-straightforward solution. I don't see any
> > conceptual problem with inline assembly being checked a bit later in
> > the
> > pipeline (it is, after all, quite target specific).
> We generally prefer to diagnose things in Sema rather than IRGen, and
> reason is that we want these diagnostics to show up in clients like
> Obviously, ASM constraint validation is a pretty minor diagnostic, but I
> don't see what naturally limits this to just that. In fact, hasn't this
> come up before?
> If this is really just specific to ASM constraint validation, I think we
> can find a way to delay the diagnosis of those to IRGen conditionally.
> Otherwise, I think you need to find a way to suppress diagnostics from
> functions that you don't care about.
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev