Hi all, I was discussing this with a few folks at the dev meeting and it would be interesting for some passes to print some warnings on a later stage than the front-end, in special cases, especially if line information is kept and available at that stage. Is this possible today? My main concern is not correctness, that should have been taken care by the front-end and the sanitizers, but things like we already do with the debug messages, only less verbose, and possibly formatted in a special way, so that other front-end tools can read and propose changes to the code. I don't have a clear picture of it yet in my mind, but I was thinking of hints like "this loop could be vectorized if you added a restrict keyword to your pointers". The vectorizer doesn't know if they alias, so it prints the warning. Then another front-end tool could read this and do some code analysis and tell the user if there is at least a few cases in the call graph in which they can't alias, and propose some code changes. This can also be used to raise bugs. Even though the debug info is already good enough for it, a flag in Clang to enable these non-verbose warnings would be more effective than a list of debug messages, and maybe the user could even figure it out by him/herself before sending the email. So instead of an email like "why doesn't my loop vectorize?", we get a bug report "implement THIS and THAT in the vectorizer", with an example of the loop. Does that make sense? This could be a nice GSOC project... cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131109/13eb5e98/attachment.html>
It seems like a difficult thing to do since we would have to keep metadata intact across transformations, which, AFAIK, is not done. mem2reg, for example, doesn't even propagate debug metadata to phi nodes, and I'm not really sure if it's valid to do so. Also, line information alone seems to be insufficient for providing accurate warnings. Debug metadata does contain variable names, but relying only on that would probably limit the kind of warnings we can emit. H. On Sat, Nov 9, 2013 at 8:27 PM, Renato Golin <renato.golin at linaro.org>wrote:> Hi all, > > I was discussing this with a few folks at the dev meeting and it would be > interesting for some passes to print some warnings on a later stage than > the front-end, in special cases, especially if line information is kept and > available at that stage. Is this possible today? > > My main concern is not correctness, that should have been taken care by > the front-end and the sanitizers, but things like we already do with the > debug messages, only less verbose, and possibly formatted in a special way, > so that other front-end tools can read and propose changes to the code. > > I don't have a clear picture of it yet in my mind, but I was thinking of > hints like "this loop could be vectorized if you added a restrict keyword > to your pointers". > > The vectorizer doesn't know if they alias, so it prints the warning. Then > another front-end tool could read this and do some code analysis and tell > the user if there is at least a few cases in the call graph in which they > can't alias, and propose some code changes. > > This can also be used to raise bugs. Even though the debug info is already > good enough for it, a flag in Clang to enable these non-verbose warnings > would be more effective than a list of debug messages, and maybe the user > could even figure it out by him/herself before sending the email. > > So instead of an email like "why doesn't my loop vectorize?", we get a bug > report "implement THIS and THAT in the vectorizer", with an example of the > loop. > > Does that make sense? This could be a nice GSOC project... > > cheers, > --renato > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131109/7556cfc5/attachment.html>
On 9 November 2013 15:03, Henrique Santos <henrique.nazare.santos at gmail.com>wrote:> It seems like a difficult thing to do since we would have to keep metadata > intact across transformations, which, AFAIK, is not done. > mem2reg, for example, doesn't even propagate debug metadata to phi nodes, > and I'm not really sure if it's valid to do so. >I understand that for most micro opts (delete, combine, coalesce, simplify, etc), this would be pointless. But for big things, like the vectorizers, it could be an interesting tool in addition to the sanitizers, since at that point, we'd have a lot more information than in the front-end (vector sizes, types, costs, etc). In those cases, I don't think we need that much debug info. Line information should be enough for big things, and that's reasonably kept, even at O3. For instance, if a loop is inlined into another function, it'll contain the original line info, which is helpful. Also, if a function is inlined into a loop, and the SLP-vectorizer has warnings, it'll also point to the original function. It shouldn't be hard to include the function name in the warning (to know where it was inlined into, for example). I'm thinking of making the optimization passes help the front-end(s), the same way PGO helps the optimization passes. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131109/2c684258/attachment.html>
On 09/11/13 23:27, Renato Golin wrote:> My main concern is not correctness, that should have been taken care by > the front-end and the sanitizers, but things like we already do with the > debug messages, only less verbose, and possibly formatted in a special > way, so that other front-end tools can read and propose changes to the code.How many such messages would be generated? If there are only a few, perhaps it isn't worth it, but if there could be hundreds of them, then perhaps it is worth it. Could a front-end reasonably transform these warnings into something meaningful to the programmer? Thinking of my own languages, or even C++, it seems like it might be impossible to translate a lower-level warning. Quite often the warnings are about things the programmer can't even control in the high-level language. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail.
On 9 November 2013 21:57, edA-qa mort-ora-y <eda-qa at disemia.com> wrote:> How many such messages would be generated? If there are only a few, > perhaps it isn't worth it, but if there could be hundreds of them, then > perhaps it is worth it. >You can already use the debug messages via opt if you want a lot of messages, but I'm thinking about something that is condensed into a fixed-format, so that front-ends don't need changing when the debug messages change (content, order, etc). Could a front-end reasonably transform these warnings into something> meaningful to the programmer?This is my main idea, yes. Thinking of my own languages, or even C++,> it seems like it might be impossible to translate a lower-level warning. > Quite often the warnings are about things the programmer can't even > control in the high-level language. >This is not my experience. At least in the loop vectorizer, some debug messages hint into adding specific keywords, moving loop invariant code out, changing the induction ranges, etc, which can all be done in C. On a higher level language, I agree, it won't help the user much, but it could help the language/compiler developer to make a better job at lowering to IR. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131109/82cea253/attachment.html>