Warnings on Opt passes

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

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.

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

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

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.

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

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. :wink:

I'll check with Quentin.

cheers,
--renato