Warnings on Opt passes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Warnings on Opt passes

Renato Golin-2
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Warnings on Opt passes

Henrique Santos-2
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 <[hidden email]> 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Warnings on Opt passes

Renato Golin-2
On 9 November 2013 15:03, Henrique Santos <[hidden email]> 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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Warnings on Opt passes

Henrique Santos-2
There was a pretty lengthy discussion on this a few months ago - http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063845.html
I think people were mostly for the idea, but I don't know how far, if at all, they implemented these ideas.
If the diagnostic/warning capabilities are good enough, I think it'll be an interesting thing to have.
Also, Paul Redmond implemented something of the sort with the vectorizer and provided a few patches in that thread. It might help for implementing, testing or reasoning about what you're proposing.

H



On Sat, Nov 9, 2013 at 9:21 PM, Renato Golin <[hidden email]> wrote:
On 9 November 2013 15:03, Henrique Santos <[hidden email]> 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



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Warnings on Opt passes

edA-qa mort-ora-y
In reply to this post by Renato Golin-2
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.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Warnings on Opt passes

Renato Golin-2
On 9 November 2013 21:57, edA-qa mort-ora-y <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Warnings on Opt passes

Renato Golin-2
In reply to this post by Henrique Santos-2
On 9 November 2013 16:59, Henrique Santos <[hidden email]> wrote:
There was a pretty lengthy discussion on this a few months ago - http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063845.html

Hi Henrique,

Thanks, that was exactly what I was looking for! My bad for not searching the list first. I could blame jet-lag, but that was just silly. ;)

I'll check with Quentin.

cheers,
--renato

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev