llvm dev - Nov 2013 - [LLVMdev] Warnings on Opt passes

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>

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>

On 9 November 2013 16:59, Henrique Santos
<henrique.nazare.santos at gmail.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131109/96d56549/attachment.html>