[LLVMdev] Warnings on Opt passes

[Henrique Santos]

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 <renato.golin at linaro.org>wrote:

> 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/051c0926/attachment.html>