[llvm-commits] [PATCH] make SCEV work in presence of llvm.dbg.*

[Dan Gohman]

Hi Török,

@llvm.dbg.stoppoint actually does read and write memory, in a
sense. It's a point where a user could stop in a debugger, and
use the debugger to both read and write memory. If the optimizers
are allowed to reorder or delete memory operations, these
intrinsics will become inconsistent with the actual program.

If it's desirable to do optimizations and there are debug
intrinsics preventing that, it would be preferable to modify or
eliminate the debug intrinsics to get them out of the way,
rather than leave them in place and letting them become
inconsistent with the actual program state. This way, a debugger
could correctly tell the user "this is optimized code, I don't
know what's going on", which is fine, rather than presenting
bogus information, which is something we'd like to avoid.  I
know several other people are thinking about how to do this;
it might be a good thing to bring up on llvmdev.

For llvm.readcyclecounter, I think it's fine to inhibit
optimizations. It's hard to understand what it means if it
doesn't :-). Do you have an example where being able to
do optimizations would be useful?

Dan

On Oct 31, 2008, at 12:20 PM, Török Edwin wrote:

> Hi,
>
> The attached patch makes BasicAA respond NoModRef for llvm.dbg.*
> intrinsics.
> This allows GVN to work in presence of llvm.dbg.*, so that SCEV will
> still be able to compute trip counts at -O1.
>
> Actually the debug intrinsics don't access anything, but making the
> intrinsic IntrNoMem, or IntrReadArgMem  causes them to be
> completely remove at -O1.
> A NoModRef answer doesn't cause them to be removed. The attached patch
> contains 2 testcases:
> - make sure tripcounts are computable for a simple case even with  
> debug info
> - make sure debug info is preserved after -O1
>
> OK to commit?
>
> While we're at it, I think llvm.readcyclecounter should be handled  
> the same
> (we don't want it to be reordered, but we don't want it to inhibit
> optimizations either)
> Should I add that to BasicAA too?
>
> Another approach would be to introduce a new attribute that specifies
> that the intrinsic doesn't access memory at all,
> but it is not allowed to be reordered, and can only be removed if  
> the BB
> is dead.
>
> Best regards,
> --Edwin
> <dbgaa.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits