llvm dev - Jun 2018 - [SROA][DebugInfo][GSoC] Testing SROA on amalgamated sqlite source

FWIW, I've raised the LICM issue here:
https://bugs.llvm.org/show_bug.cgi?id=37682

On 31 May 2018 at 13:28, Anast Gramm <anastasis.gramm2 at gmail.com>
wrote:
> Thanks,
> These are very helpful.
>
> As I understand it, SROA and LICM render some variables
> "useless" by optimizing the code to not use them. Hence we
can't debug
> them.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180604/7c2861e7/attachment.html>

Hi Greg,
> On Jun 4, 2018, at 2:18 PM, Greg Bedwell via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> FWIW, I've raised the LICM issue here:
https://bugs.llvm.org/show_bug.cgi?id=37682
LICM's behavior seems reasonable/desirable to me. I've shared my
thoughts on llvm.org/PR37682. To summarize, I don't think it's feasible
to assert that the debugger show updated values for 'total' within this
loop, because it amounts to a demand that LICM never happen. Alternatives such
as marking 'total' as unavailable, or making it appear as a non-pointer
type, have serious tradeoffs and/or can't properly model the effects of
aliasing.

vedant
> 
> On 31 May 2018 at 13:28, Anast Gramm <anastasis.gramm2 at gmail.com>
wrote:
> Thanks,
> These are very helpful.
> 
> As I understand it, SROA and LICM render some variables
> "useless" by optimizing the code to not use them. Hence we
can't debug them.
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> LICM's behavior seems reasonable/desirable to me. I've shared my
thoughts on llvm.org/PR37682. To summarize, I don't think it's feasible
to
assert that the debugger show updated values for 'total' within this
loop,
because it
> amounts to a demand that LICM never happen. Alternatives such as marking
'total' as unavailable, or making it appear as a non-pointer type, have
serious tradeoffs and/or can't properly model the effects of aliasing.

Thanks for taking a look.  Let's continue the discussion if there's any
more follow-up in the bug to prevent derailing this thread.  I agree with
everything you say, but it still makes me feel uneasy that we have a
situation where we have the information available according to the
semantics of the code the user wrote (that "total" gets updated on
every
iteration, where we have that value in a register) but we aren't able to
present that to the user because it conflicts with the reality of the
optimized code ("total" is a memory location that has the value 0
until the
loop terminates when the contents of the register are stored to it).  I'd
love a third option where we could somehow convey that information to the
user.  If that's not an option currently, we should consider a solution for
-Og mode at least.  As I mentioned in the bug, we come across poorly
compared to MSVC here in terms of quality of debugging, but vaguely
amusingly purely because it doesn't appear to hoist the store.

-Greg



On 5 June 2018 at 23:17, Vedant Kumar <vsk at apple.com> wrote:
> Hi Greg,
>
> > On Jun 4, 2018, at 2:18 PM, Greg Bedwell via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > FWIW, I've raised the LICM issue here: https://bugs.llvm.org/show_
> bug.cgi?id=37682
>
> LICM's behavior seems reasonable/desirable to me. I've shared my
thoughts
> on llvm.org/PR37682. To summarize, I don't think it's feasible to
assert
> that the debugger show updated values for 'total' within this loop,
because
> it amounts to a demand that LICM never happen. Alternatives such as marking
> 'total' as unavailable, or making it appear as a non-pointer type,
have
> serious tradeoffs and/or can't properly model the effects of aliasing.
>
> vedant
>
> >
> > On 31 May 2018 at 13:28, Anast Gramm <anastasis.gramm2 at
gmail.com> wrote:
> > Thanks,
> > These are very helpful.
> >
> > As I understand it, SROA and LICM render some variables
> > "useless" by optimizing the code to not use them. Hence we
can't debug
> them.
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://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/20180606/6ebaa556/attachment-0001.html>