llvm dev - Feb 2019 - Preserving debug metadata across optimization

Hi,

I've recently run into a problem of missing !dbg metadata after the
code has been optimized (even opt -O1).
The original code was generated using llvmlite python package and I've
verified that all instructions have their !dbg metadata present.
After optimizing the module (even opt -O1) I see that some
instructions (~25%) don't have any dbg metadata.
These are mostly getelementptr and bitcasts, but there's also few
fsubs.
One example:
  %.510.i.i = bitcast [2 x double]* %.4 to i8*
  tail call void @llvm.memset.p0i8.i64(i8* nonnull align 8 %.510.i.i, i8 0, i64
16, i1 false) #5, !dbg !2822, !alias.scope !2825, !noalias !2830

There are no memset calls in the original code. the introduced bitcast is
lacking the location metadata.
The behaviour persists across llvm-6/7/git.
Is it just a series of bugs that I'm hitting?

thanks,
Jan
-- 
Jan Vesely <jan.vesely at rutgers.edu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190220/74bfd930/attachment.sig>

Hi Jan,

On Thu, Feb 21, 2019 at 4:07 AM Jan Vesely via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I've recently run into a problem of missing !dbg metadata after the
> code has been optimized (even opt -O1).
>
> After optimizing the module (even opt -O1) I see that some
> instructions (~25%) don't have any dbg metadata.
>
> The behaviour persists across llvm-6/7/git.
> Is it just a series of bugs that I'm hitting?
>
"A series of bugs" is quite likely, many optimisation passes could
preserve
debug information better.

If you happen to have a reproducer, it'd be great if you could file a bug
report blocking one of these umbrella bugs [0, 1] so that it gets looked at.

[0] https://bugs.llvm.org/show_bug.cgi?id=38768
[1] https://bugs.llvm.org/show_bug.cgi?id=31268

--
Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190221/b7e2078e/attachment.html>

While there's no doubt bugs - there's also some intentional places where
debug locations are not preserved.

Specifically when moving instructions across basic blocks, debug locations
are intentionally removed (again, there might be some bugs where they are
/not/ removed and should be - there are always more bugs) to ensure profile
accuracy (eg: if you hoist an instruction above a conditional, then a
sample-based profiler sees that that line was executed it might incorrectly
conclude that the condition was met when it wasn't) & "jumpy"
debugging
(where your debugger goes back and forwards a lot all over the code -
though, arguably, that's accurate).

Maybe one day we'll have a bit where we can say "this instruction was
hoisted or merged" (and maybe even "this instruction comes from these
3
locations") but for now removing the location is the best option.

On Wed, Feb 20, 2019 at 8:07 PM Jan Vesely via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I've recently run into a problem of missing !dbg metadata after the
> code has been optimized (even opt -O1).
> The original code was generated using llvmlite python package and I've
> verified that all instructions have their !dbg metadata present.
> After optimizing the module (even opt -O1) I see that some
> instructions (~25%) don't have any dbg metadata.
> These are mostly getelementptr and bitcasts, but there's also few
> fsubs.
> One example:
>   %.510.i.i = bitcast [2 x double]* %.4 to i8*
>   tail call void @llvm.memset.p0i8.i64(i8* nonnull align 8 %.510.i.i, i8
> 0, i64 16, i1 false) #5, !dbg !2822, !alias.scope !2825, !noalias !2830
>
> There are no memset calls in the original code. the introduced bitcast is
> lacking the location metadata.
> The behaviour persists across llvm-6/7/git.
> Is it just a series of bugs that I'm hitting?
>
> thanks,
> Jan
> --
> Jan Vesely <jan.vesely at rutgers.edu
> >_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190221/96233d05/attachment.html>

Hi,

thank you both.
I've opened a BZ at https://bugs.llvm.org/show_bug.cgi?id=40826
I think it might be the case of metadata being intentionally dropped.
The situation in which it happens is when a matrix vector multiply function
gets inlined and fully unrolled (due to known small dimmensions) into a
caller function.
Note that the posted snippet does not produce a call to memset intrinsic.
rather a set of GEPs and LOADs shed their metadata.

regards,
Jan

On Thu, Feb 21, 2019 at 12:09 PM David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> While there's no doubt bugs - there's also some intentional places
where
> debug locations are not preserved.
>
> Specifically when moving instructions across basic blocks, debug locations
> are intentionally removed (again, there might be some bugs where they are
> /not/ removed and should be - there are always more bugs) to ensure profile
> accuracy (eg: if you hoist an instruction above a conditional, then a
> sample-based profiler sees that that line was executed it might incorrectly
> conclude that the condition was met when it wasn't) &
"jumpy" debugging
> (where your debugger goes back and forwards a lot all over the code -
> though, arguably, that's accurate).
>
> Maybe one day we'll have a bit where we can say "this instruction
was
> hoisted or merged" (and maybe even "this instruction comes from
these 3
> locations") but for now removing the location is the best option.
>
> On Wed, Feb 20, 2019 at 8:07 PM Jan Vesely via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I've recently run into a problem of missing !dbg metadata after the
>> code has been optimized (even opt -O1).
>> The original code was generated using llvmlite python package and
I've
>> verified that all instructions have their !dbg metadata present.
>> After optimizing the module (even opt -O1) I see that some
>> instructions (~25%) don't have any dbg metadata.
>> These are mostly getelementptr and bitcasts, but there's also few
>> fsubs.
>> One example:
>>   %.510.i.i = bitcast [2 x double]* %.4 to i8*
>>   tail call void @llvm.memset.p0i8.i64(i8* nonnull align 8 %.510.i.i,
i8
>> 0, i64 16, i1 false) #5, !dbg !2822, !alias.scope !2825, !noalias !2830
>>
>> There are no memset calls in the original code. the introduced bitcast
is
>> lacking the location metadata.
>> The behaviour persists across llvm-6/7/git.
>> Is it just a series of bugs that I'm hitting?
>>
>> thanks,
>> Jan
>> --
>> Jan Vesely <jan.vesely at rutgers.edu
>> >_______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190222/83fa3089/attachment.html>