<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;"><div>Hi,</div><div><br></div><div>Compared to my previous email, I have added Hal’s idea for formatting the message and pull back some idea from the "querying framework”.</div><div>Indeed, I propose to add some information in the reporting so that a front-end (more generally a client) can filter the diagnostics or take proper actions.</div><div>See the details hereafter.</div><div><br></div>On Jul 22, 2013, at 2:25 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br><div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr" 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 class="gmail_extra"><div class="gmail_quote"><br class="Apple-interchange-newline">On Mon, Jul 22, 2013 at 2:21 PM, Eric Christopher<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank" class="cremed">echristo@gmail.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; position: static; z-index: auto;"><div class="im">>> This is pretty much the same as what Quentin proposed (with the addition of the enum), isn't it?<br>>><br>><br>> Pretty close yeah.<br>><br><br></div>Another thought and alternate strategy for dealing with these sorts of things:<br><br>A much more broad set of callback machinery that allows the backend to<br>communicate values or other information back to the front end that can<br>then decide what to do. We can define an interface around this, but<br>instead of having the backend vending diagnostics we have the callback<br>take a "do something with this value" which can just be "communicate<br>it back to the front end" or a diagnostic callback can be passed down<br>from the front end, etc.<br><br>This will probably take a bit more design to get a general framework<br>set up, but imagine the usefulness of say being able to automatically<br>reschedule a jitted function to a thread with a larger default stack<br>size if the callback states that the thread size was N+1 where N is<br>the size of the stack for a thread you've created.</blockquote></div><br>FWIW, *this* is what I was trying to get across. Not that it wouldn't be a callback-based mechanism, but that it should be a fully general mechanism rather than having something to do with warnings, errors, notes, etc. If a frontend chooses to use it to produce such diagnostics, cool, but there are other use cases that the same machinery should serve.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">I like the general idea.</div><div dir="auto"><br></div><div dir="auto">To be sure I understood the proposal, let me give an example.</div><div dir="auto"><br></div><div dir="auto">** Example **</div><div dir="auto">The compiler says here is the size of the stack for Loc via a “handler” (“handler" in the sense whatever mechanism we come up to make such communication possible). Then the front-end builds the diagnostic from that information (or query for more if needed) or drops everything if it does not care about this size for instance (either it does not care at all or the size is small enough compared to its setting).</div><div dir="auto"><br></div><div dir="auto">** Comments **</div><div dir="auto">Unless we have one handler per -kind of - use, and I would like to avoid that, I think we should still provide an information on the severity of the thing we are reporting and what we are reporting.</div><div dir="auto">Basically:</div><div dir="auto">- Severity: Will the back-end abort after the information pass down or will it continue (the boolean of the previous proposal)?</div><div dir="auto">- Kind: What are we reporting (the enum from the previous proposal)?</div><div dir="auto"><br></div><div dir="auto">I also think we should be able to provide a default (formatted) message, such that a client that does not need to know what to do with the information can still print something somehow useful, especially on abort cases.</div><div dir="auto">Thus, it sounds a good thing to me to have a string with some markers to format the output plus the arguments to be used in the formatted output.</div><div dir="auto">Hal’s proposal could do the trick (although I do not know if DIDescriptor are the best thing to use here).</div><div dir="auto"><br></div><div dir="auto">** Summary **</div><div dir="auto">I am starting to think that we should be able to cover the reporting case plus some querying mechanism with something like:</div><div dir="auto">void reportSomehtingToFEHandler(enum Reporting Kind, bool IsAbort, <some information>, const char* DefautMsg, <pointer to a list of args to format in the defautMsg>)</div><div dir="auto"><br></div><div dir="auto">Where <some information> is supposed to be the class/struct/pointer to the relevant information for this kind. If it is not enough the FE should call additional APIs to get what it wants.</div><div dir="auto"><br></div><div dir="auto">This looks similar to the “classical” back-end report to front-end approach, but gives more freedom to the front-end as it can choose what to do based on the attached information.</div><div dir="auto">I also believe this will reduce the need to expose back-end APIs and speed up the process.</div><div dir="auto">However, the ability of the front-end (or client) to query the back-end is limited to the places where the back-end is reporting something. Also, if the back-end is meant to abort, the FE cannot do anything about it (e.g., the stack size is not big enough for the jitted function).</div><div dir="auto">That’s why I said it cover “some" querying mechanism.</div><div dir="auto"><br></div><div dir="auto">** Concerns **</div><div dir="auto">1. Testing.</div><div dir="auto"><br></div><div dir="auto">Assuming we will always emit these reports, relying on a front-end to filter out what is not currently relevant (e.g., we did not set the stack size warning in the FE), what will happen when we test (make check) without a front-end?</div><div dir="auto">I am afraid we will pollute all tests or we will have some difficulty to test a specific reporting.</div><div dir="auto"><br></div><div dir="auto">2. Regarding a completely query based approach, like Chris pointed out, I do not see how we can report consistent information at any given time. Also, Eric, coming back to your jit example, how could we prevent the back-end to abort if the jitted is too big for the stack?</div><div dir="auto"><br></div><div dir="auto">3. Back to the strictly reporting approach where we extend the inlineasm handler (the approach proposed by Bob and that I sketched a little bit more), now looks similar to this approach expect that the back-end chooses what it is relevant to report and the back-end does not need to pass down the information.</div><div dir="auto">The concern is how do we easily (in a robust and extendable manner) provide a front-end/back-end option for each warning/error?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Thoughts?</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto"><br></div><div dir="auto">-Quentin</div><blockquote type="cite"><span 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; float: none; display: inline !important;">_______________________________________________</span><br 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;"><span 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; float: none; display: inline !important;">LLVM Developers mailing list</span><br 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;"><a href="mailto:LLVMdev@cs.uiuc.edu" 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;">LLVMdev@cs.uiuc.edu</a><span 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; float: none; display: inline !important;"><span class="Apple-converted-space"> </span> </span><a href="http://llvm.cs.uiuc.edu/" 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;">http://llvm.cs.uiuc.edu</a><br 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;"><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" 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;">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></blockquote></div><br></body></html>