>> Have the backend vend diagnostics, this can be done either with a set >> of enums and messages like you mentioned, or just have a message and >> location struct ala: >> >> struct Msg { >> const char *Message; >> Location Loc; >> }; >> >> that the consumer of the message can use via a handler. > > When the consumer is clang, it's important that we have diagnostic groups to control the warnings, so the enum is important. We don't want to be comparing the message strings to decide whether a particular warning is an instance of -Wstack-size (for example). >I think, in this case, that I'd want the registration function to handle the "give me these sorts of warnings" rather than it be a part of the message. I.e. you'd register for each class of warnings out of the backend maybe?> > This is pretty much the same as what Quentin proposed (with the addition of the enum), isn't it? >Pretty close yeah.>> >> a) Front end diagnostics - This is an area that needs some work to be >> decent, but it involves the front end querying the back end for things >> like register size, valid immediates, etc and should be implemented by >> the front end with an expanded set of target queries. We could use >> this as a way to solidify the backend api for the MS inline asm >> support as well and use some of that when parsing GNU style inline >> asm. > > Yes, I agree about this, too. As an example, we had a discussion a few months ago about warning about over-aligned stack variables when dynamic stack realignment is disabled, and we agreed to move that warning into the frontend. I keep poking at the frontend team every once in a while to get some help implementing that, but I haven't forgotten it. >*nod* This should be pretty easy to implement out of the front end at a first thought - "if we're creating an alloca with an alignment greater than the target and we've turned off dynamic realignment then warn". The trick is getting the backend data for such things etc.>> >> b) Back end diagnostics - This is the stuff that the front end has no >> hope of diagnosing. i.e. "ran out of registers", or "can't figure out >> how to split this up into this kind of vector register". The latter >> has always been a bit funny and I'm always unhappy with it, but I >> don't have any better ideas. A unified scheme of communicating "help >> help I'm being oppressed by the front end" in the backend would be, at >> the very least, a step forward. >> >> Thoughts? > > I don't have any better ideas for this. At least if we generalize the existing inline asm diagnostic handler, it will make it less of a special case.Ah, the thoughts was an "in general", but if you'd had ideas I'd have totally been up for them :) -eric
On Mon, Jul 22, 2013 at 1:26 PM, Eric Christopher <echristo at gmail.com> wrote:>>> Have the backend vend diagnostics, this can be done either with a set >>> of enums and messages like you mentioned, or just have a message and >>> location struct ala: >>> >>> struct Msg { >>> const char *Message; >>> Location Loc; >>> }; >>> >>> that the consumer of the message can use via a handler. >> >> When the consumer is clang, it's important that we have diagnostic groups to control the warnings, so the enum is important. We don't want to be comparing the message strings to decide whether a particular warning is an instance of -Wstack-size (for example). >> > > I think, in this case, that I'd want the registration function to > handle the "give me these sorts of warnings" rather than it be a part > of the message. I.e. you'd register for each class of warnings out of > the backend maybe? > >> >> This is pretty much the same as what Quentin proposed (with the addition of the enum), isn't it? >> > > Pretty close yeah. >Another thought and alternate strategy for dealing with these sorts of things: A much more broad set of callback machinery that allows the backend to communicate values or other information back to the front end that can then decide what to do. We can define an interface around this, but instead of having the backend vending diagnostics we have the callback take a "do something with this value" which can just be "communicate it back to the front end" or a diagnostic callback can be passed down from the front end, etc. This will probably take a bit more design to get a general framework set up, but imagine the usefulness of say being able to automatically reschedule a jitted function to a thread with a larger default stack size if the callback states that the thread size was N+1 where N is the size of the stack for a thread you've created. Thoughts? -eric
On Mon, Jul 22, 2013 at 2:21 PM, Eric Christopher <echristo at gmail.com>wrote:> >> This is pretty much the same as what Quentin proposed (with the > addition of the enum), isn't it? > >> > > > > Pretty close yeah. > > > > Another thought and alternate strategy for dealing with these sorts of > things: > > A much more broad set of callback machinery that allows the backend to > communicate values or other information back to the front end that can > then decide what to do. We can define an interface around this, but > instead of having the backend vending diagnostics we have the callback > take a "do something with this value" which can just be "communicate > it back to the front end" or a diagnostic callback can be passed down > from the front end, etc. > > This will probably take a bit more design to get a general framework > set up, but imagine the usefulness of say being able to automatically > reschedule a jitted function to a thread with a larger default stack > size if the callback states that the thread size was N+1 where N is > the size of the stack for a thread you've created.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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130722/15bb2e2e/attachment.html>