[LLVMdev] Warnings on Opt passes
Henrique Santos
henrique.nazare.santos at gmail.com
Sat Nov 9 15:03:27 PST 2013
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>
More information about the llvm-dev
mailing list