<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jul 19, 2013, at 5:48 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra">Sorry for the delays, just haven't been able to get back around to this. My silence isn't about not caring.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 19, 2013 at 5:13 PM, Quentin Colombet<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank" class="cremed">qcolombet@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div>Like I summed up in my previous email (see below), there are two orthogonal approaches to this problem.</div><div>I have chosen the second one (extend the reporting already used for inline asm).</div><div><br></div><div>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.</div></blockquote></div><br>I really don't like the second approach.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div></div></blockquote><div><br></div>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.</div><div><br></div><div>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:</div><div>- severity level (warning or error)</div><div>- an enum to indicate the kind of diagnostic (InlineAsm, StackSize, etc.)</div><div><br></div><div>How is that coupling us to Clang’s warning infrastructure? It’s just a hook, and it’s very simple.</div><div><br><blockquote type="cite" dir="auto"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite" dir="auto"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div></div></blockquote><div><br></div>If we’re going to add a generic framework, shouldn’t the minimum requirement be that it support the current functionality?</div><div><br><blockquote type="cite" dir="auto"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">If anything, I think the design you are pursuing is strictly more complex and invasive, and without any tangible benefits as a consequence.</div></div></div></blockquote><br></div><div>What complexity do you see? It seems very, very simple to me.</div></body></html>