Sorry for the delays, just haven't been able to get back around to this. My silence isn't about not caring. On Fri, Jul 19, 2013 at 5:13 PM, Quentin Colombet <qcolombet at apple.com>wrote:> Like I summed up in my previous email (see below), there are two > orthogonal approaches to this problem. > I have chosen the second one (extend the reporting already used for inline > asm). > > Regarding the first approach (front-end querying the back-end to build up > diagnostic), it needs further discussion if anyone wants to go in that > direction. Although I think this is interesting, I leave that for someone > else. >I really don't like the second approach. Fundamentally, it increasingly couples LLVM to Clang's warning infrastructure and I think that's a bad thing. I think we are better served by designing good interfaces for the frontend and the backend to communicate in order for different frontends to provide different types and kinds of information to users based on their needs. Bob described one potential API for this, but I think there are much better ones. I don't think we have to be constrained by the idea of using a pass to compute and communicate this information -- there are other approaches. I haven't thought about them because I haven't designed such an interface. If I had, I would just contribute it. I do think that this is the correct design direction though, as I don't think that there is one unified way to represent diagnostics in the backend, or if there is I don't tihnk we have any idea what it looks like. Inline assembly is more of a special case than anything else. I don't really see why the right path forward is to design a generic framework around what was originally built for its specific purpose. If anything, I think the design you are pursuing is strictly more complex and invasive, and without any tangible benefits as a consequence. -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130719/f235fc30/attachment.html>
Hi Chandler,> Le 19 juil. 2013 à 17:48, Chandler Carruth <chandlerc at google.com> a écrit : > > Sorry for the delays, just haven't been able to get back around to this. My silence isn't about not caring. > >> On Fri, Jul 19, 2013 at 5:13 PM, Quentin Colombet <qcolombet at apple.com> wrote: >> Like I summed up in my previous email (see below), there are two orthogonal approaches to this problem. >> I have chosen the second one (extend the reporting already used for inline asm). >> >> Regarding the first approach (front-end querying the back-end to build up diagnostic), it needs further discussion if anyone wants to go in that direction. Although I think this is interesting, I leave that for someone else. > > I really don't like the second approach. > > Fundamentally, it increasingly couples LLVM to Clang's warning infrastructure and I think that's a bad thing. I think we are better served by designing good interfaces for the frontend and the backend to communicate in order for different frontends to provide different types and kinds of information to users based on their needs. > > Bob described one potential API for this, but I think there are much better ones. I don't think we have to be constrained by the idea of using a pass to compute and communicate this information -- there are other approaches. I haven't thought about them because I haven't designed such an interface. If I had, I would just contribute it. I do think that this is the correct design direction though, as I don't think that there is one unified way to represent diagnostics in the backend, or if there is I don't tihnk we have any idea what it looks like. > > Inline assembly is more of a special case than anything else. I don't really see why the right path forward is to design a generic framework around what was originally built for its specific purpose. > > If anything, I think the design you are pursuing is strictly more complex and invasive, and without any tangible benefits as a consequence.Fair enough. Let us go back into the discussion then :). The general question now would be what should we expose and how could we make it easily available to a front-end. Also one thing that is missing, what do we do if there is not a front end? In other words how are we supposed to abort if something bad happen when nobody is querying for diagnostics? Q. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130719/2686c307/attachment.html>
On Fri, Jul 19, 2013 at 6:46 PM, Quentin Colombet <qcolombet at apple.com> wrote:> Hi Chandler, > > Le 19 juil. 2013 à 17:48, Chandler Carruth <chandlerc at google.com> a écrit : > > Sorry for the delays, just haven't been able to get back around to this. My > silence isn't about not caring. > > On Fri, Jul 19, 2013 at 5:13 PM, Quentin Colombet <qcolombet at apple.com> > wrote: >> >> Like I summed up in my previous email (see below), there are two >> orthogonal approaches to this problem. >> I have chosen the second one (extend the reporting already used for inline >> asm). >> >> Regarding the first approach (front-end querying the back-end to build up >> diagnostic), it needs further discussion if anyone wants to go in that >> direction. Although I think this is interesting, I leave that for someone >> else. > > > I really don't like the second approach. > > Fundamentally, it increasingly couples LLVM to Clang's warning > infrastructure and I think that's a bad thing. I think we are better served > by designing good interfaces for the frontend and the backend to communicate > in order for different frontends to provide different types and kinds of > information to users based on their needs. > > Bob described one potential API for this, but I think there are much better > ones. I don't think we have to be constrained by the idea of using a pass to > compute and communicate this information -- there are other approaches. I > haven't thought about them because I haven't designed such an interface. If > I had, I would just contribute it. I do think that this is the correct > design direction though, as I don't think that there is one unified way to > represent diagnostics in the backend, or if there is I don't tihnk we have > any idea what it looks like. > > Inline assembly is more of a special case than anything else. I don't really > see why the right path forward is to design a generic framework around what > was originally built for its specific purpose. > > If anything, I think the design you are pursuing is strictly more complex > and invasive, and without any tangible benefits as a consequence. > > Fair enough. > > Let us go back into the discussion then :). > > The general question now would be what should we expose and how could we > make it easily available to a front-end. > > Also one thing that is missing, what do we do if there is not a front end? > In other words how are we supposed to abort if something bad happen when > nobody is querying for diagnostics?We can write a default diagnostic handler suitable for something like llc, where there isn't really any source code to point at. -Eli
On Jul 19, 2013, at 5:48 PM, Chandler Carruth <chandlerc at google.com> wrote:> Sorry for the delays, just haven't been able to get back around to this. My silence isn't about not caring. > > On Fri, Jul 19, 2013 at 5:13 PM, Quentin Colombet <qcolombet at apple.com> wrote: > Like I summed up in my previous email (see below), there are two orthogonal approaches to this problem. > I have chosen the second one (extend the reporting already used for inline asm). > > Regarding the first approach (front-end querying the back-end to build up diagnostic), it needs further discussion if anyone wants to go in that direction. Although I think this is interesting, I leave that for someone else. > > I really don't like the second approach. > > Fundamentally, it increasingly couples LLVM to Clang's warning infrastructure and I think that's a bad thing. I think we are better served by designing good interfaces for the frontend and the backend to communicate in order for different frontends to provide different types and kinds of information to users based on their needs.I disagree. The interface that Quentin sketched out isn’t coupling LLVM’s warnings to Clang at all. When used with Clang, it allows all of Clang’s nice diagnostic machinery to work well, but it isn’t tied to that. The proposal has a generic hook that any frontend or driver can use to be notified of warnings from LLVM. That hook would provide a simple and clean interface with just the basic information: - severity level (warning or error) - an enum to indicate the kind of diagnostic (InlineAsm, StackSize, etc.) How is that coupling us to Clang’s warning infrastructure? It’s just a hook, and it’s very simple.> > Bob described one potential API for this, but I think there are much better ones. I don't think we have to be constrained by the idea of using a pass to compute and communicate this information -- there are other approaches. I haven't thought about them because I haven't designed such an interface. If I had, I would just contribute it. I do think that this is the correct design direction though, as I don't think that there is one unified way to represent diagnostics in the backend, or if there is I don't tihnk we have any idea what it looks like.I wasn’t trying to describe a potential API. I was trying to figure out what you were proposing, and I don’t think adding new passes would work well at all. I can’t think of any reasonable way to design such an interface. Can you at least sketch out an example of what you are proposing? Without that, I think there’s really only one proposal on the table.> > Inline assembly is more of a special case than anything else. I don't really see why the right path forward is to design a generic framework around what was originally built for its specific purpose.If we’re going to add a generic framework, shouldn’t the minimum requirement be that it support the current functionality?> > If anything, I think the design you are pursuing is strictly more complex and invasive, and without any tangible benefits as a consequence.What complexity do you see? It seems very, very simple to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130720/fccad8fa/attachment.html>